allow some kernel filesystems to be mounted in a user namespace
Subsystems (3)
RFC PATCH 1/1 allow some kernel filesystems to be mounted in a user namespace
All the files will be owned by host root, so there's no security concern in allowing this.
(These are mounted by default by mountall, and if permission is denied then by default container boot will hang)
--- fs/debugfs/inode.c | 1 + fs/fuse/control.c | 1 + security/inode.c | 1 + 3 files changed, 3 insertions(+)
fs/debugfs/inode.c +1 -0
@@ -298,6 +298,7 @@ static struct file_system_type debug_fs_type = { .name = "debugfs", .mount = debug_mount, .kill_sb = kill_litter_super, + .fs_flags = FS_USERNS_MOUNT, };MODULE_ALIAS_FS ("debugfs" );
fs/fuse/control.c +1 -0
@@ -340,6 +340,7 @@ static struct file_system_type fuse_ctl_fs_type = { .name = "fusectl", .mount = fuse_ctl_mount, .kill_sb = fuse_ctl_kill_sb, + .fs_flags = FS_USERNS_MOUNT, };MODULE_ALIAS_FS ("fusectl" );
security/inode.c +1 -0
@@ -49,6 +49,7 @@ static struct file_system_type fs_type = { .name = "securityfs", .mount = get_sb, .kill_sb = kill_litter_super, + .fs_flags = FS_USERNS_MOUNT, };/**
Signature · 1 line
1.8.3.2
Quoted 2 lines · Serge Hallyn
All the files will be owned by host root, so there's no security concern in allowing this.
Files owned by root != very bad things can't be done by non-root. Especially for debugfs, which is very much a "don't even think about mounting that on a production box" thing...
Serge E. Hallyn
maintainerQuoted 7 lines · Al Viro
Quoted 2 lines · Serge Hallyn
All the files will be owned by host root, so there's no security concern in allowing this.
Files owned by root != very bad things can't be done by non-root. Especially for debugfs, which is very much a "don't even think about mounting that on a production box" thing...
I would prefer it not be mounted. But near as I can tell there should be no regression security-wise whether an unprivileged user on the host has access to it, or whether a user in a non-init user ns is allowed to mount it. (Obviously I could very well be wrong)
-serge
Quoted 9 lines · Serge E. Hallyn
Quoted 7 lines · Al Viro
Quoted 2 lines · Serge Hallyn
All the files will be owned by host root, so there's no security concern in allowing this.
Files owned by root != very bad things can't be done by non-root. Especially for debugfs, which is very much a "don't even think about mounting that on a production box" thing...
Quoted 5 lines
I would prefer it not be mounted. But near as I can tell there should be no regression security-wise whether an unprivileged user on the host has access to it, or whether a user in a non-init user ns is allowed to mount it. (Obviously I could very well be wrong)
I would argue that either (a) debugfs denies everything to non-root, so mounting it in a (rootless) userns is useless or (b) it doesn't, in which case it's dangerous.
In neither case does it make sense to me to allow the mount.
--Andy
Serge E. Hallyn
maintainerQuoted 16 lines · Andy Lutomirski
Quoted 9 lines · Serge E. Hallyn
Quoted 7 lines · Al Viro
Quoted 2 lines · Serge Hallyn
All the files will be owned by host root, so there's no security concern in allowing this.
Files owned by root != very bad things can't be done by non-root. Especially for debugfs, which is very much a "don't even think about mounting that on a production box" thing...
Quoted 5 lines
I would prefer it not be mounted. But near as I can tell there should be no regression security-wise whether an unprivileged user on the host has access to it, or whether a user in a non-init user ns is allowed to mount it. (Obviously I could very well be wrong)
Quoted 5 lines
I would argue that either (a) debugfs denies everything to non-root, so mounting it in a (rootless) userns is useless or (b) it doesn't, in which case it's dangerous.
In neither case does it make sense to me to allow the mount.
It makes sense from the POV of having sane user-space. I can obviously work around this by tweaking a stock container rootfs to be different from a stock host rootfs. It is undesirable.
For debug and fusectl there is another option which I'm happy to pursue, namely tweaking how mountall handles 'nofail' to ignore these errors.
But for /sys/kernel/security, the failure of which to mount on a non-container can be a real problem, that is not good enough. So at least I'd like securityfs to be mountable in a non-init userns.
-serge
Serge E. Hallyn
maintainerQuoted 21 lines · Serge E. Hallyn
Quoted 20 lines · Andy Lutomirski
Quoted 9 lines · Serge E. Hallyn
Quoted 7 lines · Al Viro
Quoted 2 lines · Serge Hallyn
All the files will be owned by host root, so there's no security concern in allowing this.
Files owned by root != very bad things can't be done by non-root. Especially for debugfs, which is very much a "don't even think about mounting that on a production box" thing...
Quoted 5 lines
I would prefer it not be mounted. But near as I can tell there should be no regression security-wise whether an unprivileged user on the host has access to it, or whether a user in a non-init user ns is allowed to mount it. (Obviously I could very well be wrong)
I would argue that either (a) debugfs denies everything to non-root, so mounting it in a (rootless) userns is useless or (b) it doesn't, in which case it's dangerous.
Quoted 5 lines
Quoted 1 line
In neither case does it make sense to me to allow the mount.
It makes sense from the POV of having sane user-space. I can obviously work around this by tweaking a stock container rootfs to be different from a stock host rootfs. It is undesirable.
(s/It/But that/)
Quoted 23 lines · Serge E. Hallyn
Quoted 16 lines · Andy Lutomirski
Quoted 9 lines · Serge E. Hallyn
Quoted 7 lines · Al Viro
Quoted 2 lines · Serge Hallyn
All the files will be owned by host root, so there's no security concern in allowing this.
Files owned by root != very bad things can't be done by non-root. Especially for debugfs, which is very much a "don't even think about mounting that on a production box" thing...
Quoted 5 lines
I would prefer it not be mounted. But near as I can tell there should be no regression security-wise whether an unprivileged user on the host has access to it, or whether a user in a non-init user ns is allowed to mount it. (Obviously I could very well be wrong)
Quoted 5 lines
I would argue that either (a) debugfs denies everything to non-root, so mounting it in a (rootless) userns is useless or (b) it doesn't, in which case it's dangerous.
In neither case does it make sense to me to allow the mount.
Quoted 7 lines
It makes sense from the POV of having sane user-space. I can obviously work around this by tweaking a stock container rootfs to be different from a stock host rootfs. It is undesirable.
For debug and fusectl there is another option which I'm happy to pursue, namely tweaking how mountall handles 'nofail' to ignore these errors.
I don't know enough about fuse to know whether it should work in a container, but presumably the fusectl FS needs to be aware of userns mappings for it to work right. But ISTM it would be better for containers to be smart enough to keep going if debugfs fails to mount -- this really seems like a userspace problem that ought to be fixed in userspace.
Quoted 5 lines
But for
/sys/kernel/security, the failure of which to mount on a non-container can be a real problem, that is not good enough. So at least I'd like securityfs to be mountable in a non-init userns.
Will the container work if /sys/kernel/security is inaccessible even to "root"?
Quoted 1 line
-serge
Signature · 2 lines
Andy Lutomirski AMA Capital Management, LLC
Serge E. Hallyn
maintainerQuoted 28 lines · Andy Lutomirski
Quoted 27 lines · Serge E. Hallyn
Quoted 16 lines · Andy Lutomirski
Quoted 9 lines · Serge E. Hallyn
Quoted 7 lines · Al Viro
Quoted 2 lines · Serge Hallyn
All the files will be owned by host root, so there's no security concern in allowing this.
Files owned by root != very bad things can't be done by non-root. Especially for debugfs, which is very much a "don't even think about mounting that on a production box" thing...
Quoted 5 lines
I would prefer it not be mounted. But near as I can tell there should be no regression security-wise whether an unprivileged user on the host has access to it, or whether a user in a non-init user ns is allowed to mount it. (Obviously I could very well be wrong)
Quoted 5 lines
I would argue that either (a) debugfs denies everything to non-root, so mounting it in a (rootless) userns is useless or (b) it doesn't, in which case it's dangerous.
In neither case does it make sense to me to allow the mount.
It makes sense from the POV of having sane user-space. I can obviously work around this by tweaking a stock container rootfs to be different from a stock host rootfs. It is undesirable.
Quoted 6 lines
Quoted 3 lines
For debug and fusectl there is another option which I'm happy to pursue, namely tweaking how mountall handles 'nofail' to ignore these errors.
I don't know enough about fuse to know whether it should work in a container, but presumably the fusectl FS needs to be aware of userns
Again it's not about working - we actually don't (through LSM) allow writes under any of them anyway. It's about containers and non-containers having similar boot sequences when possible.
Quoted 2 lines
mappings for it to work right. But ISTM it would be better for containers to be smart enough to keep going if debugfs fails to mount
"smart enough" in this case means finding ways to figure out information that it wouldn't otherwise need, and the form of which could at some point change, and generally just increases the future potential fragility.
Well, to be fair that's again really referring to the securityfs one. Basically solving that would require teaching mountall to parse /proc/self/uid_map to decide its namespace.
Quoted 9 lines
-- this really seems like a userspace problem that ought to be fixed in userspace.
Quoted 4 lines
But for
/sys/kernel/security, the failure of which to mount on a non-container can be a real problem, that is not good enough. So at least I'd like securityfs to be mountable in a non-init userns.Will the container work if
/sys/kernel/securityis inaccessible even to "root"?
Yes. As it is they're actually not allowed to write under there (by LSM). Containers start fine for me with these three mounted this way.
-serge
Quoted 33 lines · Serge E. Hallyn
Quoted 32 lines · Andy Lutomirski
Quoted 30 lines · Serge E. Hallyn
Quoted 16 lines · Andy Lutomirski
Quoted 9 lines · Serge E. Hallyn
Quoted 7 lines · Al Viro
Quoted 2 lines · Serge Hallyn
All the files will be owned by host root, so there's no security concern in allowing this.
Files owned by root != very bad things can't be done by non-root. Especially for debugfs, which is very much a "don't even think about mounting that on a production box" thing...
Quoted 5 lines
I would prefer it not be mounted. But near as I can tell there should be no regression security-wise whether an unprivileged user on the host has access to it, or whether a user in a non-init user ns is allowed to mount it. (Obviously I could very well be wrong)
Quoted 5 lines
I would argue that either (a) debugfs denies everything to non-root, so mounting it in a (rootless) userns is useless or (b) it doesn't, in which case it's dangerous.
In neither case does it make sense to me to allow the mount.
It makes sense from the POV of having sane user-space. I can obviously work around this by tweaking a stock container rootfs to be different from a stock host rootfs. It is undesirable.
For debug and fusectl there is another option which I'm happy to pursue, namely tweaking how mountall handles 'nofail' to ignore these errors.
Quoted 6 lines
Quoted 2 lines
I don't know enough about fuse to know whether it should work in a container, but presumably the fusectl FS needs to be aware of userns
Again it's not about working - we actually don't (through LSM) allow writes under any of them anyway. It's about containers and non-containers having similar boot sequences when possible.
I, and many other people, run kernel.org kernels with LSM disabled. userns defaults to on, and that configuration needs to be secure.
Quoted 7 lines
Quoted 3 lines
mappings for it to work right. But ISTM it would be better for containers to be smart enough to keep going if debugfs fails to mount
"smart enough" in this case means finding ways to figure out information that it wouldn't otherwise need, and the form of which could at some point change, and generally just increases the future potential fragility.
Presumably this is as simple as making 'mountall' report success if nofail is set and mount returns -EPERM.
That being said, it would probably be okay to modify debugfs to detect that it's in a nonroot userns and show up empty when mounted.
Quoted 4 lines
Well, to be fair that's again really referring to the securityfs one. Basically solving that would require teaching mountall to parse
/proc/self/uid_mapto decide its namespace.
Huh?
Quoted 9 lines
Quoted 9 lines
-- this really seems like a userspace problem that ought to be fixed in userspace.
Quoted 4 lines
But for
/sys/kernel/security, the failure of which to mount on a non-container can be a real problem, that is not good enough. So at least I'd like securityfs to be mountable in a non-init userns.
Quoted 5 lines
Quoted 1 line
Will the container work if
/sys/kernel/securityis inaccessible even to "root"?Yes. As it is they're actually not allowed to write under there (by LSM). Containers start fine for me with these three mounted this way.
At least for securityfs, relying on LSM is legit.
--Andy
Serge E. Hallyn
maintainerQuoted 37 lines · Andy Lutomirski
Quoted 36 lines · Serge E. Hallyn
Quoted 34 lines · Andy Lutomirski
Quoted 23 lines · Serge E. Hallyn
Quoted 16 lines · Andy Lutomirski
Quoted 9 lines · Serge E. Hallyn
Quoted 7 lines · Al Viro
Quoted 2 lines · Serge Hallyn
All the files will be owned by host root, so there's no security concern in allowing this.
Files owned by root != very bad things can't be done by non-root. Especially for debugfs, which is very much a "don't even think about mounting that on a production box" thing...
Quoted 5 lines
I would prefer it not be mounted. But near as I can tell there should be no regression security-wise whether an unprivileged user on the host has access to it, or whether a user in a non-init user ns is allowed to mount it. (Obviously I could very well be wrong)
Quoted 5 lines
I would argue that either (a) debugfs denies everything to non-root, so mounting it in a (rootless) userns is useless or (b) it doesn't, in which case it's dangerous.
In neither case does it make sense to me to allow the mount.
Quoted 7 lines
It makes sense from the POV of having sane user-space. I can obviously work around this by tweaking a stock container rootfs to be different from a stock host rootfs. It is undesirable.
For debug and fusectl there is another option which I'm happy to pursue, namely tweaking how mountall handles 'nofail' to ignore these errors.
I don't know enough about fuse to know whether it should work in a container, but presumably the fusectl FS needs to be aware of userns
Quoted 6 lines
Quoted 3 lines
Again it's not about working - we actually don't (through LSM) allow writes under any of them anyway. It's about containers and non-containers having similar boot sequences when possible.
I, and many other people, run kernel.org kernels with LSM disabled. userns defaults to on, and that configuration needs to be secure.
My point was just that not being able to write under those mounts will not break the containers. I'm not saying it would be ok to push this patch is it did require an LSM to be safe.
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
mappings for it to work right. But ISTM it would be better for containers to be smart enough to keep going if debugfs fails to mount
"smart enough" in this case means finding ways to figure out information that it wouldn't otherwise need, and the form of which could at some point change, and generally just increases the future potential fragility.
Quoted 5 lines
Presumably this is as simple as making 'mountall' report success if nofail is set and mount returns
-EPERM.That being said, it would probably be okay to modify debugfs to detect that it's in a nonroot userns and show up empty when mounted.
That'd obviously work for containers.
Quoted 5 lines
Quoted 3 lines
Well, to be fair that's again really referring to the securityfs one. Basically solving that would require teaching mountall to parse
/proc/self/uid_mapto decide its namespace.Huh?
I don't think it's going to be ok to have mountall proceed on real hosts with /sys/kernel/security not mounted, risking the expected security policy *quietly* not being setup on hosts.
That's why I consider it better and safer to simply allow the securityfs mount.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
-- this really seems like a userspace problem that ought to be fixed in userspace.
Quoted 4 lines
But for
/sys/kernel/security, the failure of which to mount on a non-container can be a real problem, that is not good enough. So at least I'd like securityfs to be mountable in a non-init userns.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Will the container work if
/sys/kernel/securityis inaccessible even to "root"?Yes. As it is they're actually not allowed to write under there (by LSM). Containers start fine for me with these three mounted this way.
At least for securityfs, relying on LSM is legit.
I'm not "relying on LSM" to make these safe. I'm relying on the uid mappings to make these safe.
Nevertheless I at least have hope of working around the others (in a distro-acceptable way), so if the others are too scary I'll pursue the workaround for the others and see where I get. But I really feel the securityfs one is the best solution.
thanks,
-serge
Quoted 7 lines · Serge E. Hallyn
I'm not "relying on LSM" to make these safe. I'm relying on the uid mappings to make these safe.
Nevertheless I at least have hope of working around the others (in a distro-acceptable way), so if the others are too scary I'll pursue the workaround for the others and see where I get. But I really feel the securityfs one is the best solution.
Personally I don't trust debugfs enough to compile it into my kernel.
fuse simply isn't ready to be have fresh mounts usefully created inside a user namespace.
Fundamentally with debugfs and securityfs you run into the issue we saw with sysfs and proc where at some level it is the system administrators perogative if those filesystems should be mounted.
The rule with filesystems like that is mounting them needs to be no more dangerous than bind mounting them. At the point in the cycle you are talking about mounting them you presumably have already thrown away their original mounts making it impossible to tell if it would have been safe to mount them or not. Making your patch completely inappropriate.
What you need to do is at container setup time to bind mount those filesystems if they are already mounted and you want them in the container. If you are just shuffling around something you can already see there are no security issues.
Eric
Quoted 11 lines · Eric W. Biederman
Quoted 7 lines · Serge E. Hallyn
I'm not "relying on LSM" to make these safe. I'm relying on the uid mappings to make these safe.
Nevertheless I at least have hope of working around the others (in a distro-acceptable way), so if the others are too scary I'll pursue the workaround for the others and see where I get. But I really feel the securityfs one is the best solution.
Personally I don't trust debugfs enough to compile it into my kernel.
That, again, seems reasonable, but would also seem to invalidate objections to this patch :) but,
Quoted 7 lines
fuse simply isn't ready to be have fresh mounts usefully created inside a user namespace.
Fundamentally with debugfs and securityfs you run into the issue we saw with sysfs and proc where at some level it is the system administrators perogative if those filesystems should be mounted.
Quoted 5 lines
The rule with filesystems like that is mounting them needs to be no more dangerous than bind mounting them. At the point in the cycle you are talking about mounting them you presumably have already thrown away their original mounts making it impossible to tell if it would have been safe to mount them or not. Making your patch completely inappropriate.
Right so the specific problem this patch introduces is: An admin who is using a distro kernel with these filesystems enabled but not mounted, without this patch does not have to worry about unprivileged users being able to access the fs. With this patch, he does.
Thanks everyone, I withdraw this patch.
Quoted 4 lines
What you need to do is at container setup time to bind mount those filesystems if they are already mounted and you want them in the container. If you are just shuffling around something you can already see there are no security issues.
-serge