我遇到了安全团队的问题,因为工程团队希望FUSE在Docker中挂载文件系统,但是,为此必须设置“ --cap-add SYS_ADMIN”标志。安全性不允许此标志。
我在Internet上发现了很多有关Docker运行时期间的“ --cap-add SYS_ADMIN”标志的文章,请谨慎,因为“ SYS_ADMIN本身会授予很大一部分功能,并且可能呈现更多的攻击面。“
但是,我找不到任何明确说明这些功能是什么以及它们呈现的“攻击面”?
SYS_ADMIN标志究竟授予什么?
通过设置此标志会带来什么实际的安全风险?
这基本上是对主机的root访问。从功能手册页:
CAP_SYS_ADMIN注意:此功能过载;请参阅内核说明开发人员,如下。
* Perform a range of system administration operations including: quotactl(2), mount(2), umount(2), pivot_root(2), setdomainname(2); * perform privileged syslog(2) operations (since Linux 2.6.37, CAP_SYSLOG should be used to permit such operations); * perform VM86_REQUEST_IRQ vm86(2) command; * perform IPC_SET and IPC_RMID operations on arbitrary System V IPC objects; * override RLIMIT_NPROC resource limit; * perform operations on trusted and security Extended Attributes (see xattr(7)); * use lookup_dcookie(2); * use ioprio_set(2) to assign IOPRIO_CLASS_RT and (before Linux 2.6.25) IOPRIO_CLASS_IDLE I/O scheduling classes; * forge PID when passing socket credentials via UNIX domain sockets; * exceed /proc/sys/fs/file-max, the system-wide limit on the number of open files, in system calls that open files (e.g., accept(2), execve(2), open(2), pipe(2)); * employ CLONE_* flags that create new namespaces with clone(2) and unshare(2) (but, since Linux 3.8, creating user namespaces does not require any capability); * call perf_event_open(2); * access privileged perf event information; * call setns(2) (requires CAP_SYS_ADMIN in the target namespace); * call fanotify_init(2); * call bpf(2); * perform privileged KEYCTL_CHOWN and KEYCTL_SETPERM keyctl(2) operations; * perform madvise(2) MADV_HWPOISON operation; * employ the TIOCSTI ioctl(2) to insert characters into the input queue of a terminal other than the caller's controlling terminal; * employ the obsolete nfsservctl(2) system call; * employ the obsolete bdflush(2) system call; * perform various privileged block-device ioctl(2) operations; * perform various privileged filesystem ioctl(2) operations; * perform privileged ioctl(2) operations on the /dev/random device (see random(4)); * install a seccomp(2) filter without first having to set the no_new_privs thread attribute; * modify allow/deny rules for device control groups; * employ the ptrace(2) PTRACE_SECCOMP_GET_FILTER operation to dump tracee's seccomp filters; * employ the ptrace(2) PTRACE_SETOPTIONS operation to suspend the tracee's seccomp protections (i.e., the PTRACE_O_SUSPEND_SECCOMP flag); * perform administrative operations on many device drivers. * Modify autogroup nice values by writing to /proc/[pid]/autogroup (see sched(7)).