3 ms·

> Namespaces (of which there are many, so 'unpriveleged' must be qualified) != cgroup controllers (of which there are similarly many) != capabilities (of which

by cyphar 10y ago

> Namespaces (of which there are many, so 'unpriveleged' must be qualified) != cgroup controllers (of which there are similarly many) != capabilities (of which there are also may). You're correct that namespaces != cgroups. But capabilities are actually part of namespaces (well, specifically the user namespace but a lot of permission checks in the kernel depend on other namespaces and having capabilities in pinned namespaces). So while you could say that capabilities != namespaces it's not really accurate since they are quite inter-related. Not to mention that every process is in a set of cgroups and namespaces and has a set of capability sets. As for the specific example of mknod, here's a link to the relevant kernel source[1]. You're not correct in your assumption. cgroups and namespaces are separate when you are actually administrating them, and they are wholly separate subsystems. However, at the end of the day any security policy will have to be applied to whatever syscalls they apply to. capable(CAP_MKNOD) is a namespace check, and devcgroup_inode_mknod is a cgroup check. > I strongly suspect that your impression comes from container userland runtime system specific code I read the kernel code for namespaces and cgroups all the time when debugging issues. I'm well aware how containers work from both the userspace abstraction side as well as the kernel side (and have written kernel code for containers too). > and I strongly doubt it is kernel code, but am always more than willing to be re-educated. See the link[1] for the example of mknod. My point was that both cgroups and namespaces gate the requirements for creating new devices. And that makes logical sense because any user can create a new user namespace with full capabilities, but the device cgroup rules aren't changed by doing that (so it would allow for unprivileged users to do all sorts of bad things as a result). [1]: https://github.com/torvalds/linux/blob/fe82203b63e598c34d96e846dea49679a726fc7a/fs/namei.c#L3660 https://github.com/torvalds/linux/blob/fe82203b63e598c34d96e...

contingencies 10y ago
Yes, obviously mknod is capability checked in the kernel, as there is a capability with that very name. Where else would it occur? I never suggested otherwise. My point was that in your talk and comments you make some suggestions which I feel are misleading or inaccurate. In some cases this is probably because you are discussing your own implementation. In other cases this is because I believe your use of terminology is incorrect or misleading, eg. capabilities are not 'part of' namespaces, any more than block devices are 'part of' the filesystem. Similarly, the phrase 'unprivileged namespace' comes across as exceptionally obtuse, given that most security checks occur in other kernel subsystems, and a holistic conception is implied by the word 'unpriveleged'. Naming is hard, but kernel terminology should already be consistent. I can't see us getting anywhere further with this discussion but an honest thanks for taking the time to respond.
- cyphar 10y ago
  > Yes, obviously mknod is capability checked in the kernel, as there is a capability with that very name. Yes, and it's checked against the root user namespace, not your current one. Which means that it's not as simple as "do I have this capability". It's "do I have this capability in this user namespace". Which is what I said originally, so I'm not sure what you're debating here. > My point was that in your talk and comments you make some suggestions which I feel are misleading or inaccurate. In some cases this is probably because you are discussing your own implementation. Can you give some examples? If I'm wrong about something, I'd love to see an example of it so I can correct it in the future. In particular, I'd like to know what parts of my discussion are related to runC's implementation of containers. > capabilities are not 'part of' namespaces, any more than block devices are 'part of' the filesystem Capabilities are effectively 4 bitmasks that are scoped to user namespaces. Yes, they aren't technically part of "struct user_namespace_t" but the way they are used make them quite intricately related. Much more intricately related than block device inodes in a filesystem. > given that most security checks occur in other kernel subsystems, and a holistic conception is implied by the word 'unpriveleged'. But those security checks generally will use either ns_capable (so they're all hooked up to the user namespace scoping logic), basic UID/GID checks (which are also hooked up to user namespace mapping logic) or some other security framework that is effectively an additional ACL (and isn't the purview of namespaces anyway). The main complaint I would understand from the use of "unprivileged namespace" is that the kernel doesn't actually mark namespaces as being privileged or unprivileged, it just so happens that unprivileged namespaces act slightly differently because of how they are set up. But AFAICS that's not the argument you're making.

by cyphar 10y ago

contingencies 10y ago

Yes, obviously mknod is capability checked in the kernel, as there is a capability with that very name. Where else would it occur? I never suggested otherwise. My point was that in your talk and comments you make some suggestions which I feel are misleading or inaccurate. In some cases this is probably because you are discussing your own implementation. In other cases this is because I believe your use of terminology is incorrect or misleading, eg. capabilities are not 'part of' namespaces, any more than block devices are 'part of' the filesystem. Similarly, the phrase 'unprivileged namespace' comes across as exceptionally obtuse, given that most security checks occur in other kernel subsystems, and a holistic conception is implied by the word 'unpriveleged'. Naming is hard, but kernel terminology should already be consistent. I can't see us getting anywhere further with this discussion but an honest thanks for taking the time to respond.

cyphar 10y ago
> Yes, obviously mknod is capability checked in the kernel, as there is a capability with that very name. Yes, and it's checked against the root user namespace, not your current one. Which means that it's not as simple as "do I have this capability". It's "do I have this capability in this user namespace". Which is what I said originally, so I'm not sure what you're debating here. > My point was that in your talk and comments you make some suggestions which I feel are misleading or inaccurate. In some cases this is probably because you are discussing your own implementation. Can you give some examples? If I'm wrong about something, I'd love to see an example of it so I can correct it in the future. In particular, I'd like to know what parts of my discussion are related to runC's implementation of containers. > capabilities are not 'part of' namespaces, any more than block devices are 'part of' the filesystem Capabilities are effectively 4 bitmasks that are scoped to user namespaces. Yes, they aren't technically part of "struct user_namespace_t" but the way they are used make them quite intricately related. Much more intricately related than block device inodes in a filesystem. > given that most security checks occur in other kernel subsystems, and a holistic conception is implied by the word 'unpriveleged'. But those security checks generally will use either ns_capable (so they're all hooked up to the user namespace scoping logic), basic UID/GID checks (which are also hooked up to user namespace mapping logic) or some other security framework that is effectively an additional ACL (and isn't the purview of namespaces anyway). The main complaint I would understand from the use of "unprivileged namespace" is that the kernel doesn't actually mark namespaces as being privileged or unprivileged, it just so happens that unprivileged namespaces act slightly differently because of how they are set up. But AFAICS that's not the argument you're making.