[Bug 213135] CVE-2008-2544 mounting proc readonly on a different mount point silently mounts it rw if the /proc mount is rw

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=213135

--- Comment #21 from Martin Cracauer   2009-01-12 14:32:01 EDT ---
This is definitely not fixed.

Here is a summary of the issue.  From memory, some details might be out of
focus.

1) when using a chroot for any kind of non-trivial application, including web
browsers and seti-at-home type applications you need a /proc, let's say you
mount it to /chroot/proc.

2) of course a read-write mounted /chroot/proc will instantly turn security
into a joke (as all processes, files and devices are accessible by anybody
becoming root in the chroot).  But most of these applications, while requiring
a /proc, can live with a readonly /proc.

So people like me want two procfs mounts:
- /proc read-write
- /chroot/proc read-only

This is b0rked.

3) the Linux kernel, stock or Redhat, does not support multiple mounts of
procfs with different permissions

4) in the mainline kernel, if you have an existing read-write mount to /proc
and make a mount request to a read-only /chroot/proc, it will ignore the
readonly flag silently and give you a read-write mounted /chroot/proc instead.

5) in redhat/fedora kernels around the time of my initial bug report, and
presumably today: given an existing read-write mount to /proc and  a mount
request to a read-only /chroot/proc, it will downgrade /proc to read-only,
effectively disabling the base system.

I think the solution for this must be some kind of "wrapper" filesystem that
can put a read-only layer on top of an existing filesystem.

In any case, both behaviors as described in 4) and 5) are unacceptable. 
Silently giving read-write permissions on a read-only mount request is as wrong
as silently downgrading an existing mount.

%%

I strongly urge somebody who is running a recent Fedora to re-open this bug
report after confirming which behavior it is showing now.  I had
cut'n'pasteable reproducing commands in my original bug report and can supply
them again.