19

I am running into issues with security teams because engineering teams want to FUSE mount a filesystem in Docker, however, to do that, the "--cap-add SYS_ADMIN" flag must be set. Security is not allowing this flag.

I have found a lot of articles on the Internet regarding the "--cap-add SYS_ADMIN" flag during the Docker runtime as something to be cautious of because "SYS_ADMIN by itself grants quite a big part of the capabilities and it could potentially present more attack surface."

However, I cannot find anything which specifically states what these capabilities are and what "attack surfaces" they present?

What exactly does the SYS_ADMIN flag grant?

What is a practical security risk that is presented by setting this flag?

Chris C
  • 1,012
  • 2
  • 12
  • 19

1 Answers1

16

This is basically root access to the host. From the capabilities man page:

CAP_SYS_ADMIN Note: this capability is overloaded; see Notes to kernel developers, below.

          * 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)).
BMitch
  • 231,797
  • 42
  • 475
  • 450
  • By "host" you mean the system that runs the container? Or are these privileges limited to the system inside the container? If a running docker container with `CAP_SYS_ADMIN` privilege has somehow access to the system that runs this container, can you give an example on how this privilege can be applied? – goulashsoup Sep 05 '22 at 14:11
  • 2
    @goulashsoup the list of syscalls that get exposed is listed above. Not all of those syscalls are isolated to a namespace. No matter how many containers you run, there's only a single kernel processing those syscalls for the host and containers on the host. In particular, mount, bpf, clone, setns, seccomp, and ptrace all look promising. – BMitch Sep 05 '22 at 14:37
  • But in case I run a Linux docker container on Windows the docker container can NOT just use the hosts kernel, simply because Windows has different syscalls then Linux does, or is that a misconception? – goulashsoup Sep 06 '22 at 08:01
  • 1
    You don't run Linux containers on a Windows host. Instead, you run a Linux VM on Windows, and that VM runs containers. So the question becomes how important is the security of the VM, particularly since it has quite a bit of access granted back into the Windows filesystem. – BMitch Sep 06 '22 at 09:11