oss-sec mailing list archives
Re: Re: CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts
From: Daniel Micay <danielmicay () gmail com>
Date: Sat, 28 Feb 2015 18:35:06 -0500
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.
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts Daniel Micay (Feb 26)
- Re: CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts Daniel Micay (Feb 26)
- Re: Re: CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts Rich Felker (Feb 28)
- Re: Re: CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts Daniel Micay (Feb 28)
- Re: CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts Steven Stewart-Gallus (Mar 01)
- Re: Re: CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts Rich Felker (Feb 28)
- Re: CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts Daniel Micay (Feb 26)