Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Feb 2015 12:55:13 -0500
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
CC: sstewartgallus00@...angara.bc.ca, ryao@...too.org
Subject: CVE request: Linux kernel silently ignores MS_RDONLY for bind mounts

This has been an issue in the kernel for a long time (likely since bind
mounts were introduced), and a patch does exist to fix it but it hasn't
been applied.

Here's the bug report:

https://bugzilla.kernel.org/show_bug.cgi?id=24912

Here's the latest iteration of the patch:

https://lkml.org/lkml/2014/11/5/911

This is not only something that software developers will expect to work,
but AFAIK it has always been intended to work. I don't think there's any
disagreement that this is a bug. Leaving the directory tree writable
when it's supposed to be read-only without reporting an error is very
problematic.

The widely used workaround (among people who realize it doesn't work) is
to remount the bind mount as read-only. That can open up a race and it
also doesn't mix well with MS_REC. The remount call will only apply the
read-only flag to the top-level mount despite MS_REC.

In systemd, there are various features suffering from security flaws due
to this kernel bug. The ReadOnlyDirectories for units only applies to
the top-level mount and systemd-nspawn's --bind-ro switch doesn't make
the submounts read-only. The flaws in systemd are documented so a CVE
assignment for those issues wouldn't make sense. I think they'd be
willing to fix these if the underlying kernel bug is dealt with.


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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.