4 ms·
> In this context, we'd like to remark that an application like Firefox only needs CAP_SYS_ADMIN, CAP_SYS_CHROOT, CAP_SET(UG)ID to achieve most effect I hope t
by the8472 9y ago
> In this context, we'd like to remark that an application like Firefox only needs CAP_SYS_ADMIN, CAP_SYS_CHROOT, CAP_SET(UG)ID to achieve most effect
I hope they also drop those capabilities once they have achieved what they need. I also which other namespaces they use, the article only mentions user namespaces.
- tialaramex 9y agoCAP_SYS_ADMIN is a catch-all where they dump all the things root has that didn't fall into another bucket. So if a program needs CAP_SYS_ADMIN then basically you haven't really got any meaningful sandboxing so far as I understand it.
- tux3 9y agoOutside a namespace, CAP_SYS_ADMIN is enough to grant yourself any other capability, but inside a namespace the main danger is that it exposes a bit more kernel attack surface than a normal user would have. The important question is whether the APIs that CAP_SYS_ADMIN and other capabiloities grants you access to are potential security issues in an user namespace. Dropping things like CAP_NET_ADMIN in a namespace is useful, because helps reduce the attack surface further.
- usr1106 9y agoRight, CAP_SYS_ADMIN has been described as the new root. It gives the sandbox more rights than what a normal user process would have. Well, capability checks are often carried out against a resource. Their namespace does probably not own many resources. So I would like to see a detailed analysis what doors CAP_SYS_ADMIN really opens. But I am very skeptical that this the right thing to do. I wonder why they need CAP_SYS_ADMIN. I have used unprivilegded containers before. We needed to make some ugly compromises to have them do useful work, but CAP_SYS_ADMIN has never been required.