Description of problem:
Martin Cracaucer (more info in BZ#213135) has reported the following
Mounting /proc filesystem via chroot command silently mounts it in readwrite
mode. See Steps To Reproduce command for more details.
The user could bypass the chroot environment and gain write access to
files, he would never have otherwise.
Affected kernel versions:
2.6.24.+ kernels as released in the Fedora distro (the case of 22.214.171.124-42.fc8
Steps To Reproduce:
1, Create chroot environment for unprivileged user (have used that one
provided by the "mock" tool) - F8 case
a, root@host] yum install / update mock
b, root@host] adduser -G mock boinc
c, root@host] passwd boinc
From another tty:
d, ssh boinc@host
e, boinc@host] mock init
(This will create the needed chroot environment for us -- root in
/var/lib/mock/fedora-development-x86_64/root/ in this case).
Return to the first tty:
g, root@host] userdel -r boinc
h, root@host] mkdir /var/lib/moc/fedora-development-x86_64/root/home/boinc
i, root@host] chown boinc.boinc
j, root@host] adduser -G mock -d
k, root@host] passwd boinc
Return to the second tty -- check the work of the chroot environment:
l, ssh boinc@host
m, boinc@host] pwd
(The output of this command should be the same as the directory used
after the -d option, in the above "useradd -G mock-d ... boinc" command).
n, boinc@host] mkdir sdf
2, Mount the root /proc filesystem via the chroot command readonly:
a, chroot /var/lib/mock/fedora-development-x86_64/root/ mount -t proc -r proc
3, Check if sdf is mounted:
boinc@host] cd sdf && ls
(There should be a couple of files listed in the output..)
4, Now try to write from root account some value to some file contained in the
chrooted mounted /proc environment (of course select such one, not
to cause kernel panic):
a, root@host] # cat
b, root@host] # echo "32768 60000" >
(There you can see /proc is mounted in readwrite mode, not in readonly
mode as it should). To check this fact perform the command
c, root@host]# cat
When the system wouldn't be vulnerable, the output of the last above command
would look like this:
# echo "32768 60000" >
Read-only file system
Martin, are you still experiencing this problem on recent versions of Fedora? Will you be able to help us reproduce the problem?
I haven't used any newer FCs.
However, it is my understanding that the kernel (before Redhat/Fedora changes) poses the original problem, you cannot have procfs mounted multiple times with different readonly or read-write status.
I would very much like to see this bug fixed (I think it counts as a bug, in particular since it happens silently). Security in a chroot is more of a joke than normal due to the read-write mounted /proc.
The only alternative is to not give the chroot any /proc, but way too many applications depend on it by now. In my environment the example is Adobe Flash. I choot my Firefox chain including plugins and Flash won't do without /proc. But it only needs readonly /proc, so if this bug was fixed that would work nicely.
Anyway, as I said, this is a general kernel issue and not a Fedora/Redhat issue. Fedora/Redhat changes the default behavior which made me report this bug against Redhat, but that was just messing with the symptoms, Redhat didn't break it.
If Redhat has the engineering resources to contribute kernel changes to allow multiple procfs mounts with different permissions I believe that would be well-invested security work.
It turns out that this is a non-issue. vfsmounts are separate, while superblock is shared. If you want your vfsmount to be read-only, you need to:
mount -o remount,ro --bind <your mount point>
Filesystem itself will remain r/w (it *is* shared with the entire system), but any write access to it via that mount will fail with EROFS until you remount it rw on vfsmount level (as above, with s/ro/rw/).
To mount this read-only, you need to do this:
# mount -t proc none /tmp/proc
# mount -o remount,ro --bind /tmp/proc
# mount | grep tmp.proc
none on /tmp/proc type proc (ro,bind)
# grep tmp.proc /proc/mounts
none /tmp/proc proc ro 0 0
# echo 1 > /tmp/proc/sys/kernel/vsyscall64
-bash: vsyscall64: Read-only file system
This is documented in mount(2).