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]
Message-ID: <22a584ab-db2b-813c-6f48-3840f56ee6cf@oracle.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ