5 ms·

> About ~9min in your talk on a user namespace slide you talk about device creation restrictions implying it is linked to user namespaces [...] No, mknod() is

by cyphar 10y ago

> About ~9min in your talk on a user namespace slide you talk about device creation restrictions implying it is linked to user namespaces [...] No, mknod() is also gated by a capable(CAP_MKNOD) check if the node is a character or block device (see vfs_mknod). Which you can't have if you've created an unprivileged namespace. Devices cgroup is an additional restriction but you hit capable(CAP_MKNOD) long before that check. > Similarly at 19:50 or so I believe the statements about things not working only apply to some container system The entire talk is about rootless containers, so I'm specifically talking about the case where you have only mapped a single user and don't have the ability to modify cgroups. I'm well aware how to grant access to devices if you have root -- the whole point of rootless containers is that you don't have root. ;) > Re: ~32:50 + crystal balling: [...] Yeah, I wrote that slide about 10 minutes before my talk. My point was that I'm really hoping one day we see containers (or specifically the sandboxing capabilities of containers) be integrated into normal applications and extended to the point where every user uses this stuff. And as you said, the main benefit is that you can then apply a bunch of useful security profiles that knock out the low-hanging fruit.

contingencies 10y ago
No, mknod() is also gated by a capable(CAP_MKNOD) check if the node is a character or block device (see vfs_mknod). Which you can't have if you've created an unprivileged namespace. Devices cgroup is an additional restriction but you hit capable(CAP_MKNOD) long before that check. 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 many). IIRC these are separate and no use of one implies the other. Therefore I do not understand your comment and believe it may be in error, as it seemed both in your talk and in this reply that you are implying a link is now implied at the kernel level. I strongly suspect that your impression comes from container userland runtime system specific code (in which my "for some of these comments it depends which container runtime you are using" comment stands), and I strongly doubt it is kernel code, but am always more than willing to be re-educated.
- 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.

by cyphar 10y ago

contingencies 10y ago

No, mknod() is also gated by a capable(CAP_MKNOD) check if the node is a character or block device (see vfs_mknod). Which you can't have if you've created an unprivileged namespace. Devices cgroup is an additional restriction but you hit capable(CAP_MKNOD) long before that check. 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 many). IIRC these are separate and no use of one implies the other. Therefore I do not understand your comment and believe it may be in error, as it seemed both in your talk and in this reply that you are implying a link is now implied at the kernel level. I strongly suspect that your impression comes from container userland runtime system specific code (in which my "for some of these comments it depends which container runtime you are using" comment stands), and I strongly doubt it is kernel code, but am always more than willing to be re-educated.

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.