[英]Cannot open uid_map for writing from an app with cap_setuid capability set
在擺弄user_namespaces(7)的示例時,我遇到了一種奇怪的行為。
應用程序user-ns-ex
使用CLONE_NEWUSER調用clone(2),從而在新的用戶命名空間中創建一個新進程。 父進程將映射( 0 1000 1
)寫入/ proc // uid_map文件,並(通過管道)告訴子進程可以繼續。 然后,子進程執行bash
。
我已經在這里復制了源代碼。
如果我沒有設置功能或全部功能,則應用程序會打開/ proc // uid_map進行編寫。
當我僅設置set_capuid,set_capgid和可選的cap_sys_admin時,對open(2)的調用失敗:
設置上限:
arksnote linux-namespaces # setcap 'cap_setuid,cap_setgid,cap_sys_admin=epi' ./user-ns-ex
arksnote linux-namespaces # getcap ./user-ns-ex
./user-ns-ex = cap_setgid,cap_setuid,cap_sys_admin+eip
嘗試運行:
kamyshev@arksnote ~/workspace/personal/linux-kernel/linux-namespaces $ ./user-ns-ex -v -U -M '0 1000 1' bash
./user-ns-ex: PID of child created by clone() is 19666
ERROR: open /proc/19666/uid_map: Permission denied
About to exec bash
無功能:
arksnote linux-namespaces # setcap '=' ./user-ns-ex
arksnote linux-namespaces # getcap ./user-ns-ex
./user-ns-ex =
運行正常:
kamyshev@arksnote ~/workspace/personal/linux-kernel/linux-namespaces $ ./user-ns-ex -v -U -M '0 1000 1' bash
./user-ns-ex: PID of child created by clone() is 19557
About to exec bash
arksnote linux-namespaces # exit
我一直在嘗試在手冊頁中查找原因,並嘗試使用不同的功能,但到目前為止沒有運氣。 最讓我困惑的是,該應用程序運行時功能較少,而運行時功能卻不足。
有人可以幫我解決這個問題嗎?
我找到了原因。 在我的reasearch中,我發現uid_map
文件未打開,因為其所有權已更改為root
。
無特權的流程,無功能:
parent(m): capabilities: '='
parent(m): file /proc/4644/uid_map owner uid: 1000
parent(m): file /proc/4644/uid_map owner gid: 1000
非特權進程,功能已設置(cap_setuid = pe):
parent(m): capabilities: '= cap_setuid+ep'
parent(m): file /proc/4644/uid_map owner uid: 0
parent(m): file /proc/4644/uid_map owner gid: 0
ERROR: open /proc/4668/uid_map: Permission denied
以下研究使我想到了這個話題: 是什么原因導致proc pid資源由root擁有?
這是發生了什么:
1)當進程不可轉儲時,其/proc/<pid>
索引節點被賦予根所有權:
// linux/base.c
struct inode *proc_pid_make_inode(struct super_block * sb, struct task_struct *task)
...
if (task_dumpable(task)) {
rcu_read_lock();
cred = __task_cred(task);
inode->i_uid = cred->euid;
inode->i_gid = cred->egid;
rcu_read_unlock();
}
2)僅當其“ dumpable”屬性的值為1(SUID_DUMP_USER)時,該過程才可轉儲。 參見ptrace(2) 。
3) prctl(2)進一步清除了這種情況:
Normally, this flag is set to 1. However, it is reset to the current value contained in the file /proc/sys/fs/suid_dumpable (which by default has the value 0), in the following circumstances: * The process's effective user or group ID is changed. * The process's filesystem user or group ID is changed (see credentials(7)). * The process executes (execve(2)) a set-user-ID or set- group-ID program, resulting in a change of either the effective user ID or the effective group ID. * The process executes (execve(2)) a program that has file capabilities (see capabilities(7)), but only if the permitted capabilities gained exceed those already permitted for the process.
因此,我的問題來自上述規則的最后一個:
int commit_creds(struct cred *new)
<...>
/* dumpability changes */
if (!uid_eq(old->euid, new->euid) ||
!gid_eq(old->egid, new->egid) ||
!uid_eq(old->fsuid, new->fsuid) ||
!gid_eq(old->fsgid, new->fsgid) ||
!cred_cap_issubset(old, new)) {
if (task->mm)
set_dumpable(task->mm, suid_dumpable);
有多種方法可以解決此問題:
/proc/sys/fs/suid_dumpable
: echo 1 > /proc/sys/fs/suid_dumpable
prctl(PR_SET_DUMPABLE, 1, 0, 0, 0)
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.