linux-kernel - Re: Semantics of blktrace with lockdown (integrity) enabled kernel.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 10 Apr 2023 15:31:15 -0700
From:   Junxiao Bi <junxiao.bi@...cle.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, jmorris@...ei.org,
        serge@...lyn.com, nathanl@...ux.ibm.com, joe.jin@...cle.com,
        Eric <eric.snowberg@...cle.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>, axboe@...nel.dk
Subject: Re: Semantics of blktrace with lockdown (integrity) enabled kernel.

On 4/10/23 3:00 PM, Paul Moore wrote:

>>> Well, you could always submit a patch* and we would review it like any
>>> other; that's usually a much better approach.
>>>
>>> * Yes, there was a patch submitted, but it was against a distro kernel
>>> that diverged significantly from the upstream kernel in the relevant
>>> areas.
>> Sure, i will submit a new one.
>>
>> Before that, may i ask this question? It may affect the approach of the
>> patch.
>>
>> Lockdown blocked files with mmap operation even that files are
>> read-only, may i know what's the security concern there?
>>
>> static int debugfs_locked_down(struct inode *inode,
>>                      struct file *filp,
>>                      const struct file_operations *real_fops)
>> {
>>       if ((inode->i_mode & 07777 & ~0444) == 0 &&
>>           !(filp->f_mode & FMODE_WRITE) &&
>>           !real_fops->unlocked_ioctl &&
>>           !real_fops->compat_ioctl &&
>>           !real_fops->mmap)
>>           return 0;
>>
>>       if (security_locked_down(LOCKDOWN_DEBUGFS))
>>           return -EPERM;
>>
>>       return 0;
>> }
> I think the comment block at the top of that function describes it well:
>
> /*
>   * Only permit access to world-readable files when the kernel is locked down.
>   * We also need to exclude any file that has ways to write or alter it as root
>   * can bypass the permissions check.
>   */

I may have some misunderstanding of  commit 5496197f9b08("debugfs: 
Restrict debugfs when the kernel is locked down"),  it mentioned chmod 
is disabled for debugfs file, so i thought permission of debugfs file 
can not be changed. Actually I just tested that, the permission can be 
changed! I am not sure whether this is an issue or not. Anyway i 
understand the security concern with mmap, thanks a lot.

Thanks,

Junxiao.

>
> --
> paul-moore.com