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: Tue, 30 Jan 2024 01:56:47 +1100
From: Aleksa Sarai <cyphar@...har.com>
To: 孟敬姿 <mengjingzi@....ac.cn>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: Identified Redundant Capability Check in File Access under
 /proc/sys

On 2024-01-28, 孟敬姿 <mengjingzi@....ac.cn> wrote:
> Hello developers,
> 
> I hope this message finds you well. I wanted to bring to your
> attention an observation regarding file access under /proc/sys in the
> kernel source code.
> 
> Upon review, it appears that certain files are protected by
> capabilities in the kernel source code; however, the capability check
> does not seem to be effectively enforced during file access.
> 
> For example, I noticed this inconsistency in the access functions of some special files:
> 1. The access function mmap_min_addr_handler() in /proc/sys/vm/mmap_min_addr utilizes the CAP_SYS_RAWIO check.
> 2. The access function proc_dointvec_minmax_sysadmin() in /proc/sys/kernel/kptr_restrict requires the CAP_SYS_ADMIN check.
> 
> Despite these capability checks in the source code, when accessing a
> file, it undergoes a UGO permission check before triggering these
> specialized file access functions. The UGO permissions for these files
> are configured as root:root rw- r-- r--, meaning only the root user
> can pass the UGO check.
> 
> As a result, to access these files, one must be the root user, who
> inherently possesses all capabilities. Consequently, the capabilities
> check in the file access function seems redundant.
> 
> Please consider reviewing and adjusting the capability checks in the
> mentioned access functions for better alignment with the UGO
> permissions.

These are not redundant -- opening a file and writing to a file
descriptor are different operations that can be done by:

 1. The same process with the same credential set (what you're
    describing);
 2. The same process but with the write operation happening after a
    setuid() or similar operation that changed its credentials; or
 3. A different process that has been given access to the file
    descriptor (passing it as an open file to a subprocess, SCM_RIGHTS,
	etc.)

On Unix, access checks when opening a file for writing are different to
access checks when doing a write operation. For some sysctls, it is
prudent to restrict both the open and write operations to privileged
users.

> Thank you for your attention to this matter.
> 
> Best regards,
> Jingzi Meng

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ