proposal to refine capability checks when _rlimit_overlimit() is true

proposal to refine capability checks when _rlimit_overlimit() is true

[孟敬姿]

Hi!

We observed a potential refinement in the kernel/fork.c line 2368. Currently, both CAP_SYS_ADMIN and CAP_SYS_RESOURCE are checked when the limit is over system limit. We suggest considering an adjustment to utilize CAP_SYS_RESOURCE exclusively. Here's our rationale for this suggestion:

(1) Defined Capability for Resource Access: According to the capability manual page[1], the capability explicitly defined for bypassing resource limits is CAP_SYS_RESOURCE. This capability is designed to provide the necessary privileges for accessing system resources without over-privileging with the broader CAP_SYS_ADMIN.

(2) Maintaining Least Privilege: CAP_SYS_ASMIN is already overloaded and known as the new "root"[2]. The use of CAP_SYS_ADMIN in this context might inadvertently over-privilege the system by providing more capabilities than necessary. And according to capability 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.

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

Your insights 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/

Re: proposal to refine capability checks when _rlimit_overlimit() is true

[Greg KH]

On Wed, Jan 03, 2024 at 11:12:28AM +0800, 孟敬姿 wrote:
> Hi!
> 
> We observed a potential refinement in the kernel/fork.c line 2368.
> Currently, both CAP_SYS_ADMIN and CAP_SYS_RESOURCE are checked when
> the limit is over system limit. We suggest considering an adjustment
> to utilize CAP_SYS_RESOURCE exclusively. Here's our rationale for this
> suggestion:

As I said when you proposed changing CAP permissions on the tty ioctls,
have you tried this and seen what actually breaks by doing so?  Please
audit the userspace code out there to ensure that what you are
attempting to propose actually would work, and then, if so, submit a
patch to do so.  Attempts of "wouldn't it be nice", don't go very far as
it shows that the work to do so hasn't actually been done.

thanks,

greg k-h

Re: proposal to refine capability checks when _rlimit_overlimit() is true

[Theodore Ts'o]

On Wed, Jan 03, 2024 at 07:11:18AM +0100, Greg KH wrote:
> On Wed, Jan 03, 2024 at 11:12:28AM +0800, 孟敬姿 wrote:
> > Hi!
> > 
> > We observed a potential refinement in the kernel/fork.c line 2368.
> > Currently, both CAP_SYS_ADMIN and CAP_SYS_RESOURCE are checked when
> > the limit is over system limit. We suggest considering an adjustment
> > to utilize CAP_SYS_RESOURCE exclusively. Here's our rationale for this
> > suggestion:
> 
> As I said when you proposed changing CAP permissions on the tty ioctls,
> have you tried this and seen what actually breaks by doing so?  Please
> audit the userspace code out there to ensure that what you are
> attempting to propose actually would work, and then, if so, submit a
> patch to do so.  Attempts of "wouldn't it be nice", don't go very far as
> it shows that the work to do so hasn't actually been done.

It's not just a matter of "auditing the userspace code", but how
systems might be set up.  So doing this could very easily cause
various systems to break based on how system administrators might have
set up their system.

What capabilities are used to add appropriate permissions is
fundamentally making a potential user space interface, and so it is
incredibly risky.  So any time we make such changes, we need to make a
very careful cost/benefit analysis.

						- Ted

Re: proposal to refine capability checks when _rlimit_overlimit() is true

[孟敬姿]

I understand change the code here may affect the world outside the
kernel. And there might be useability issues when applications in 
userspace are not updated. But the good news is that the 
modification's impact on userspace is relatively contained. 
Here's a breakdown: 

1. Usage statistics for the latest version of Ubuntu show that 
   applications have limited use of capability. 
        (1) Under the default configuration, only 28 processes in 
            Ubuntu 22.04 LTS were found to have capability, with 15 
            running as root and unaffected by the proposed change. 
        (2) Among the 59k packages on Ubuntu 21.10, only 29 programs 
            were configured with capability.[1]

2. For programs that use capability, it is not complicated for developers
   or sysadmin to reconfigure it. Programs using capability can be 
   categorized into two types: 
        (1) those started by root have full capability by default, which 
            can be changed with the prctl system call.
        (2) and those with capabilities configured directly on the 
            executable file can be modified by secap command directly.

So the key to using capability is to choose the least privilege that 
will accomplish the function. This can't be done without the kernel's 
clear delineation of privileges.

This change will make it clear that if you only need to cross system 
limits, then sys_resource is the capability you need. This may cause 
some processes that are using sys_admin to bypass limits to fail, but 
from a least privilege point of view, it may be good to reduce the 
unnecessary use of sys_admin.

Best regards,
Jingzi

[1] Hasan, Md Mehedi, Seyedhamed Ghavamnia, and Michalis Polychronakis. 
    "Decap: Deprivileging programs by reducing their capabilities." 
    Proceedings of the 25th International Symposium on Research in Attacks,
    Intrusions and Defenses. 2022.