mirror of https://gitee.com/openkylin/linux.git
prctl: Allow local CAP_CHECKPOINT_RESTORE to change /proc/self/exe
Originally, only a local CAP_SYS_ADMIN could change the exe link, making it difficult for doing checkpoint/restore without CAP_SYS_ADMIN. This commit adds CAP_CHECKPOINT_RESTORE in addition to CAP_SYS_ADMIN for permitting changing the exe link. The following describes the history of the /proc/self/exe permission checks as it may be difficult to understand what decisions lead to this point. * [1] May 2012: This commit introduces the ability of changing /proc/self/exe if the user is CAP_SYS_RESOURCE capable. In the related discussion [2], no clear thread model is presented for what could happen if the /proc/self/exe changes multiple times, or why would the admin be at the mercy of userspace. * [3] Oct 2014: This commit introduces a new API to change /proc/self/exe. The permission no longer checks for CAP_SYS_RESOURCE, but instead checks if the current user is root (uid=0) in its local namespace. In the related discussion [4] it is said that "Controlling exe_fd without privileges may turn out to be dangerous. At least things like tomoyo examine it for making policy decisions (see tomoyo_manager())." * [5] Dec 2016: This commit removes the restriction to change /proc/self/exe at most once. The related discussion [6] informs that the audit subsystem relies on the exe symlink, presumably audit_log_d_path_exe() in kernel/audit.c. * [7] May 2017: This commit changed the check from uid==0 to local CAP_SYS_ADMIN. No discussion. * [8] July 2020: A PoC to spoof any program's /proc/self/exe via ptrace is demonstrated Overall, the concrete points that were made to retain capability checks around changing the exe symlink is that tomoyo_manager() and audit_log_d_path_exe() uses the exe_file path. Christian Brauner said that relying on /proc/<pid>/exe being immutable (or guarded by caps) in a sake of security is a bit misleading. It can only be used as a hint without any guarantees of what code is being executed once execve() returns to userspace. Christian suggested that in the future, we could call audit_log() or similar to inform the admin of all exe link changes, instead of attempting to provide security guarantees via permission checks. However, this proposed change requires the understanding of the security implications in the tomoyo/audit subsystems. [1]b32dfe3771
("c/r: prctl: add ability to set new mm_struct::exe_file") [2] https://lore.kernel.org/patchwork/patch/292515/ [3]f606b77f1a
("prctl: PR_SET_MM -- introduce PR_SET_MM_MAP operation") [4] https://lore.kernel.org/patchwork/patch/479359/ [5]3fb4afd9a5
("prctl: remove one-shot limitation for changing exe link") [6] https://lore.kernel.org/patchwork/patch/697304/ [7]4d28df6152
("prctl: Allow local CAP_SYS_ADMIN changing exe_file") [8] https://github.com/nviennot/run_as_exe Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com> Signed-off-by: Adrian Reber <areber@redhat.com> Link: https://lore.kernel.org/r/20200719100418.2112740-6-areber@redhat.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This commit is contained in:
parent
12886f8ab1
commit
ebd6de6812
11
kernel/sys.c
11
kernel/sys.c
|
@ -2007,11 +2007,14 @@ static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data
|
|||
|
||||
if (prctl_map.exe_fd != (u32)-1) {
|
||||
/*
|
||||
* Make sure the caller has the rights to
|
||||
* change /proc/pid/exe link: only local sys admin should
|
||||
* be allowed to.
|
||||
* Check if the current user is checkpoint/restore capable.
|
||||
* At the time of this writing, it checks for CAP_SYS_ADMIN
|
||||
* or CAP_CHECKPOINT_RESTORE.
|
||||
* Note that a user with access to ptrace can masquerade an
|
||||
* arbitrary program as any executable, even setuid ones.
|
||||
* This may have implications in the tomoyo subsystem.
|
||||
*/
|
||||
if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN))
|
||||
if (!checkpoint_restore_ns_capable(current_user_ns()))
|
||||
return -EINVAL;
|
||||
|
||||
error = prctl_set_mm_exe_file(mm, prctl_map.exe_fd);
|
||||
|
|
Loading…
Reference in New Issue