From: 孟敬姿 <mengjingzi@iie.ac.cn>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Greg KH" <gregkh@linuxfoundation.org>,
brauner@kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org
Subject: Re: proposal to refine capability checks when _rlimit_overlimit() is true
Date: Tue, 9 Jan 2024 19:45:27 +0800 (GMT+08:00) [thread overview]
Message-ID: <7d2df0e7.174cd.18cee0ab373.Coremail.mengjingzi@iie.ac.cn> (raw)
In-Reply-To: <20240103173002.GB136592@mit.edu>
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.
prev parent reply other threads:[~2024-01-09 11:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 3:12 孟敬姿
2024-01-03 6:11 ` Greg KH
2024-01-03 17:30 ` Theodore Ts'o
2024-01-09 11:45 ` 孟敬姿 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7d2df0e7.174cd.18cee0ab373.Coremail.mengjingzi@iie.ac.cn \
--to=mengjingzi@iie.ac.cn \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®