linux-kernel - Recommendation for Capability Check Refinement in pipe_is_unprivileged

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>] [day] [month] [year] [list]

Message-ID: <4f19e1c5.cd08.18ccd7393c4.Coremail.mengjingzi@iie.ac.cn>
Date: Wed, 3 Jan 2024 11:52:32 +0800 (GMT+08:00)
From: 孟敬姿 <mengjingzi@....ac.cn>
To: iro@...iv.linux.org.uk, brauner@...nel.org
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Recommendation for Capability Check Refinement in
 pipe_is_unprivileged_user()

Hi!

We noted a potential refinement in the pipe_is_unprivileged_user() function where CAP_SYS_ADMIN and CAP_SYS_RESOURCE are checked when pipe buffer size exceeds the system limit. Having either one will pass the check. However, we propose adjusting this to exclusively use CAP_SYS_RESOURCE. Here's our rationale for this suggestion:

(1) Distinct Capabilities for Resource Limits: The capability manual page[1] clearly defines CAP_SYS_RESOURCE as the capability used to bypass system resource limits. Introducing a check for CAP_SYS_ADMIN might be misleading, as it is a separate capability with a different scope.

(2) Maintaining Least Privilege Principle: CAP_SYS_ASMIN is already overloaded and known as the new "root"[2], but it is still an independent capability and should not be overlapped with others. According to the manual page[1] “Don't choose CAP_SYS_ADMIN if you can possibly avoid it!”, it's beneficial to use the most specific capability required for a given task. In this context, utilizing CAP_SYS_RESOURCE exclusively ensures that only the necessary permissions are granted without over-privileging with the broader CAP_SYS_ADMIN.

This issue exists in several kernel versions and we have checked it on the latest stable release(Linux 6.6.9). 

Your thoughts and feedback on this proposed modification would be highly appreciated. Thank you for your time and consideration.

Best regards,
Jingzi

reference:
[1] https://www.man7.org/linux/man-pages/man7/capabilities.7.html
[2] https://lwn.net/Articles/486306/