Rationale for the default set of capabilities with rootless podman (linux)?

[iustin]

I was trying to run nft list ruleset under a rootless container, but to my surprise it failed, because NET_ADMIN is missing. I couldn't find an explanation for the list of default capabilities that podman configures, and not being very versed with it, I don't know how safe it is to just add NET_ADMIN.

I checked docs/source/markdown/options/cap-add.md but it only gives very general advice, and advises about adding more when not using a user namespace. I think the default list is in https://github.com/containers/common/blob/a5ccdae846b629b5ceaefa6ffd5c6511409c3487/pkg/config/default.go#L107, but with no explanation on why this list and not another.

Thinking some more, probably the default list too conservative for rootless podman, but I'm not sure. Thoughts? Happy to improve documentation afterwards.

[baude]

the default caps have been derived over the years of development with podman and feedback from users. i think the default caps, where they stand rn, is ... while arguably conservative ... the right balance for now? Thats one maintainer's opinion.

[iustin]

Just to be clear, I'm not arguing the set is not good. I'm trying to find information whether the rationale for the current set is documented, and hopefully if I understand the situation a bit, document in more detail.

For one thing, I think a single set for both of root and root-less is too conservative, but I am not sure I understand well how capabilities interact with user name spaces, so I'm not confident on that yet.

So, just looking for more information for now.

[Luap99]

Restrictive in what sense?

Handing out NET_ADMIN is never something we would consider doing by default, the container could reconfigure their network interface and try to spoof other containers on the same bridge network so that would be a security problem.
Also historically there have been some CVEs in the netfilter code were crafted packets could lead to an exploit.

The ideal list would be no capabilities not more. IIRC originally the default set was copied form docker and then we removed the ones we do not think people needed and where most people did not complain. Finding a good balance there is likely impossible.

The point is if you know your container needs a certain capability you can always add it explicitly which is much better instead of giving it out to any container.