与仅使用CLONE_NEWUSER相比,如何以更细粒度的方式启用kernel.unprivileged_userns_clone?
我希望通过禁用非根CAP_SYS_ADMIN或BPF之类的新的和复杂的东西来保持内核API攻击面的可管理性,但也有选择地允许某些特定的程序使用它。
例如,chrome-sandbox需要CLOSE_NEWUSER或suid-root来进行正确的操作,但我不希望所有的程序都能够使用如此复杂的技巧,只有少数几个已批准的技巧。
发布于 2022-11-27 21:32:26
如果不创建自定义内核修补程序,这是不可能的。注意,这个特定于Debian的sysctl 不受欢迎。禁用用户命名空间的方法是user.max_user_namespaces = 0。
kernel/user_namespace.c:create_user_ns()创建了一个新的用户名称空间。在允许创建一个新的命名空间之前,会进行几次检查,但是没有什么表明能够在每个文件或每个用户的基础上控制这个名称空间。这是很不幸的,但是许多内核开发人员在全局基础上启用非特权用户命名空间的不明白风险。
一个样本(未经测试!)修补程序只允许UID 1234在内核6.0中创建新的命名空间:
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -86,6 +86,10 @@ int create_user_ns(struct cred *new)
struct ucounts *ucounts;
int ret, i;
+ ret = -EPERM;
+ if (!uid_eq(current_uid(), KUIDT_INIT(1234)))
+ goto fail;
+
ret = -ENOSPC;
if (parent_ns->level > 32)
goto fail;https://unix.stackexchange.com/questions/726413
复制相似问题