Date: Sat, 28 Feb 2015 18:35:06 -0500 From: Daniel Micay <danielmicay@...il.com> To: oss-security@...ts.openwall.com Subject: Re: Re: CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts On 28/02/15 03:38 PM, Rich Felker wrote: > On Thu, Feb 26, 2015 at 02:58:17PM -0500, Daniel Micay wrote: >> The commit adding this in 2.6.26 did actually document the weird >> behaviour, so I guess it's just "by design". Users of the API like LXC, >> Docker and systemd would likely have to iterate over /proc/self/mounts >> and remount everything due to the way MS_REC works. Anyway, there's >> clearly something wrong here when containers are claiming to have a >> read-only mount feature but writes to the directory tree aren't prevented... > > I'm wondering what the actual impact of this issue is supposed to be. > Why would any of the uids inside the container have write access to a > shared filesystem on which their uids are presumably not even > meaningful? It seems to me like this would only affect world-writable > files/directories on the shared filesystem, which sound like a bad > idea to begin with. It's true that in many cases it's meaningless, but it does have value when it's just a non-root user in a mount namespace (no NEWUSER) or if the gid/uid maps are set up to allow writes to some rw bind mounts. The distinction between rw and ro mounts in these tools may not be very useful, but if it's there it should be implemented sanely. Mount namespaces are also being used by systemd and other tools as a coarse form of access control, essentially to work around the inability to mix and match LSMs. It doesn't really do what it says on the tin due to the submount issue, and I doubt that all of the projects using it realize that. It would also be a lot more sensible for systemd to drop MS_REC if it's supposed to be read-only or put in the effort to do it properly. Documenting the flaw is great... but it should just work. It would be better to use the right tool for the job here (MAC) but projects want these features in a portable way and since LSMs can't be mixed together (other than Yama) they can't just pick one and ship a policy as distributions haven't settled on a common denominator. I don't think it's a serious issue, but I'm bothered by the kernel just silently ignoring MS_RDONLY and forcing various userspace projects to use a half-working hack to work around it. Anyway, I thought this was an old neglected bug that everyone just decided to work around rather than an intended part of the design. I was trying to bring some attention to it, but in hindsight it didn't make sense to make the thread. Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ