SYS_ADMIN capability given to a docker conainer

[goci...@gmail.com]

It is recommended to avoid giving a `privileged` to the container, if it possible. Instead of, docker user is encouraged to use `--cap-add SYS_ADMIN` (for example). 

But, for my eye:

--cap-add SYS_ADMIN` is equivalent to `--privileged` 

Why?

From documentation you can read that:  http://man7.org/linux/man-pages/man7/capabilities.7.html

CAP_SYS_ADMIN makes you possible to:

 call setns(2) (requires CAP_SYS_ADMIN in the target namespace);

(Is it possible to "namespace" capabilities?**). AFAIK it is not. 

    docker run --cap-add SYS_ADMIN ubuntu sleep 360 (id that container= d8243d6019b0)

    

    docker exec d8243d6019b0 getpcaps 1 (1 is pid of sleep)

    Capabilities for `1': = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,**cap_sys_admin**,cap_mknod,cap_audit_write,cap_setfcap+eip

And;

    getpcaps 32735 (32735 is a pid of sleep in main(root) namespace)

    Capabilities for `32735': = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,**cap_sys_admin**,cap_mknod,cap_audit_write,cap_setfcap+eip

So, the container has cap_sys_admin both in `container namespace` and `host namespace`.

As a result, the container can `nsset` to host namespace.

My questions is:

1. Is it possible to "namespace" capabilities?**

2. Is my reasoning correct and true? 

[Michael Crosby]

Its not recommend to use either.  I in the context of `privileged`, its encouraging you to not use the blanket `--privileged` flag that enables everything but the user should find the specific set of capabilities that their container requires to perform the required action.

For example if you have an application that needs to modify iptables or routes then you would not set SYS_ADMIN but NET_ADMIN to only enable privileged network operations.  

There is more behind the privileged flag than just one capability(apparmor, seccomp, etc...).

[goci...@gmail.com]

Thanks, but please note that my question was another.

[Michael Crosby]

1. caps are placed on a process, not the namespace.  operations/syscalls maybe namespaced others are not. 

2. reasoning about what?  containers are as secure as their users make them to be.  if you poke holes in the container by adding caps, sharing the host namespaces, etc then you will be performing operations on the host depending on what you configured.   

--

You received this message because you are subscribed to the Google Groups "docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to docker-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-----------------------------------------

Michael Crosby

@crosbymichael

[Michael Crosby]

I believe that is referring to setns on a user namespace.  Is not clear what is referred to as the target user namespace.  The man pages are really confusing...

http://man7.org/linux/man-pages/man7/user_namespaces.7.html

A single-threaded
       process can join another user namespace with setns(2) if it has the
       CAP_SYS_ADMIN in that namespace;

http://man7.org/linux/man-pages/man2/setns.2.html

       A process reassociating itself with a user namespace must have the
       CAP_SYS_ADMIN capability in the target user namespace.  Upon
       successfully joining a user namespace, a process is granted all
       capabilities in that namespace, regardless of its user and group IDs.

On Mon, Oct 16, 2017 at 3:01 PM, <goci...@gmail.com> wrote:

1. caps are placed on a process, not the namespace.  operations/syscalls maybe namespaced others are not. 

 call setns(2) (requires CAP_SYS_ADMIN in the target namespace);

So, what does mean a documentation? 

W dniu poniedziałek, 16 października 2017 20:55:44 UTC+2 użytkownik Michael Crosby napisał:

1. caps are placed on a process, not the namespace.  operations/syscalls maybe namespaced others are not. 

2. reasoning about what?  containers are as secure as their users make them to be.  if you poke holes in the container by adding caps, sharing the host namespaces, etc then you will be performing operations on the host depending on what you configured.   

On Mon, Oct 16, 2017 at 2:47 PM, <goci...@gmail.com> wrote:

Thanks, but please note that my question was another.

W dniu poniedziałek, 16 października 2017 17:04:01 UTC+2 użytkownik Michael Crosby napisał:

Its not recommend to use either.  I in the context of `privileged`, its encouraging you to not use the blanket `--privileged` flag that enables everything but the user should find the specific set of capabilities that their container requires to perform the required action.

For example if you have an application that needs to modify iptables or routes then you would not set SYS_ADMIN but NET_ADMIN to only enable privileged network operations.  

There is more behind the privileged flag than just one capability(apparmor, seccomp, etc...).

--

You received this message because you are subscribed to the Google Groups "docker-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to docker-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-----------------------------------------

Michael Crosby

@crosbymichael

--
You received this message because you are subscribed to the Google Groups "docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to docker-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[goci...@gmail.com]

1. caps are placed on a process, not the namespace.  operations/syscalls maybe namespaced others are not. 

 call setns(2) (requires CAP_SYS_ADMIN in the target namespace);

So, what does a documentation mean?

– pokaż cytowany tekst –

[Muayyad AlSadi]

You are totally right both are equivalent of giving full root accesd to host

http://rhelblog.redhat.com/2016/10/17/secure-your-containers-with-this-one-weird-trick/

https://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-run-docker-in-centos-fedora-or-rhel/

[goci...@gmail.com]

@Michel Crosby, so we can concluded that: 

I am trying to summarize:

1. It is possible to "namespace" capabilities using user namespace. So, process X can make everything in a container (namespace) whileas it cannot "nothing" outside a container (in root namespace). 

2. If use user namespace in a docker we can make is impossible to join main/root/host namespace, yes? So, in that way we are able  to get a CAP_SYS_ADMIN for process and it is safe- the process run in the container is harmless for the kernel

Am I right?

A process reassociating itself with a user namespace must have the
CAP_SYS_ADMIN capability in the target user namespace. Upon
successfully joining a user namespace, a process is granted all
capabilities in that namespace, regardless of its user and group IDs.

So, if we use user namespace the process from container cannot join to usernamespace. But, can it join to other namespaces, like filesystem/PID namespaces? 

W dniu poniedziałek, 16 października 2017 16:47:30 UTC+2 użytkownik goci...@gmail.com napisał: