Security best practice when special capabilities are needed

[mario19911]

It is not really a bug or a feature, just a question about security.

I have a pod in which multiple containers are running...some of these containers do not need special capabilities whereas others need the capability to start realtime tasks, use unprivileged ports, raw sockets and so on.

As far as I know it is possible with podman to start the container as root, drop all privileges and assign only the privileges that are really needed. Together with --user I can also prevent the direct mapping from root to root between container and host. The container is still started with the root user...

My question is now: is this the best someone can do regarding security? Or are there other methods? E.g. assign capabilities to the podman executable and run start the containers as unprivileges user?

[mheon]

@rhatdan Does --userns=auto work with pods? That wouldn't help with attacks within the pod but would insulate the rest of the system from the pod.

[rhatdan]

Man page says it does, and I know @cdoern worked on adding this functionality.

[mario19911]

I just tried the option for the podman run command:
podman run -it --userns=auto --cap-add cap_sys_nice,cap_sys_time -v /home/test:/usr/bin realtime /bin/bash

When executing my realtime-program I get the error "no permission". Also when trying to set the time I have the same problem.

On the other hand with the command
podman run -it --cap-add cap_sys_nice,cap_sys_time -v /home/test:/usr/bin realtime /bin/bash
everything is working fine!

Is there some limitation within a user namespace? It seems that the capabilities are not preserved...

[mheon]

You’ll need to set it for the entire pod, by adding it to the pod create command line.

…

On Tue, Mar 8, 2022 at 00:16 mario19911 ***@***.***> wrote: I just tried the option for the podman run command: podman run -it --userns=auto --cap-add cap_sys_nice,cap_sys_time -v /home/test:/usr/bin realtime /bin/bash When executing my realtime-program I get the error "no permission". Also when trying to set the time I have the same problem. On the other hand with the command podman run -it --cap-add cap_sys_nice,cap_sys_time -v /home/test:/usr/bin realtime /bin/bash everything is working fine! Is there some limitation within a user namespace? It seems that the capabilities are not preserved... — Reply to this email directly, view it on GitHub <#13444 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCAPD3H5NZBIXHEV5O3U63PB5ANCNFSM5QDJR4KQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[mheon]

Though, using cap-add with it may not do what you expect in general, as user namespaces lose access to the real capabilities of the system in favor of more limited emulated capabilities.

…

On Tue, Mar 8, 2022 at 08:06 Matthew Heon ***@***.***> wrote: You’ll need to set it for the entire pod, by adding it to the pod create command line. On Tue, Mar 8, 2022 at 00:16 mario19911 ***@***.***> wrote: > I just tried the option for the podman run command: > podman run -it --userns=auto --cap-add cap_sys_nice,cap_sys_time -v > /home/test:/usr/bin realtime /bin/bash > > When executing my realtime-program I get the error "no permission". Also > when trying to set the time I have the same problem. > > On the other hand with the command > podman run -it --cap-add cap_sys_nice,cap_sys_time -v /home/test:/usr/bin > realtime /bin/bash > everything is working fine! > > Is there some limitation within a user namespace? It seems that the > capabilities are not preserved... > > — > Reply to this email directly, view it on GitHub > <#13444 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB3AOCAPD3H5NZBIXHEV5O3U63PB5ANCNFSM5QDJR4KQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you commented.Message ID: > ***@***.***> >

[rhatdan]

A rootless user is not going to be allowed to set the system time, without or without a usernamespaced CAP_SYS_TIME capability.

[rhatdan]

Converting this issue to a discussion.

[cdoern]

@umohnani8 worked on the userns flag for pods I worked on security-opt. It is possible to add additional security options per container (I think) but the ones from pod creation will be applied to the containr as well which could lead to conflicting options. I could work on a way to override pod specific options but I do not know if that is a good idea...