Virtual filesystem mounts could use more restrictive mount options

[hunger]

After reading about a recent root exploit that used the /proc filesystem and could have been stopped by applying restrictive permissions to the filesystem I decided to check my ubuntu machine.

All the filesystems set up by ubuntu itself (/dev, /proc, /sys, /var/run, /var/lock, etc.) are mounted rw by default. This is a potential security risk that can be fixed by adding a couple of lines to /etc/fstab!

My fstab reads like this now:
# kernel FS:
proc /proc proc nodev,noexec,nosuid 0 0
sysfs /sys sys nodev,noexec,nosuid 0 0
udev /dev tmpfs nosuid 0 0
varrun /var/run tmpfs nodev,noexec,nosuid 0 0
varlock /var/lock tmps nodev,noexec,nosuid 0 0

/dev/shm and /dev/pts could probably do with a noexec,nosuid as well, but I am not sure enough to add those at the moment;-)

The linux-restricted-modules could even be mounted nodev,noexec,nosuid as well.

You might want to think about adding more restrictive permissions to user-created filesystems by default as well.
Eg. /home works fine with nosuid and stops users from storing stolen root shells;-)

All this can be easily done by editing /etc/fstab, but ubuntu is about being secure by default, so a user should not need to do that himself IMHO.

[Martin Pitt (pitti)]

Indeed this sounds like an unintrusive, but effective change. We should confine this to new installs, though.

[hunger (hunger)]

I disagree there:

In my opinion ubuntu must make sure that its internal workings are as secure as possible, especially when introducing them after a sysadmin has set up and verified his system to be reasonably secure.

And these filesystems are ubuntu internals! Some of them were even introduced to systems during an upgrade (/var/run and /var/lock during the dapper cycle), so they were not even there during the initial system audit.

You will rewrite /etc/fstab to add UUIDs in edgy anyway, I do not see why that script could not add a couple of lines with permissions.

[hunger (hunger)]

Pitti said it is a good idea, I count that as confirmation;-)

[Matt Zimmerman (mdz)]

/proc should not be mounted read-only; this would break sysctls and other important functionality. I expect it should be safe to mount it nosuid, though. Subscribing the kernel team for other input on this.

[hunger (hunger)]

Matt, I never suggested mounting /proc readonly!

It is a collection of data-files (from a filesystem point of view at least). So nodev (no devices here), noexec (no executables either) and nosuid (definitly no suid executables) should be OK.

In fact everything but /dev should be save to get mounted nodev...

[Matt Zimmerman (mdz)]

On Fri, Aug 04, 2006 at 03:03:05PM -0000, hunger wrote:
> Matt, I never suggested mounting /proc readonly!

"All the filesystems set up by ubuntu itself (/dev, /proc, /sys, /var/run,
/var/lock, etc.) are mounted rw by default. This is a potential security
risk that can be fixed..."

--
 - mdz

[hunger (hunger)]

Ah, OK, I see. That sentence can be misunderstood, sorry for that.

What I meant is that when doing "mount" all those filesystems are listed as mounted with the option "(rw)". They could (and in my opinion should) be mounted eg. "(rw,noexec,nodev)" instead.

[hunger (hunger)]

I went ahead and modified a couple of files to apply more restrictive mount options to the virtual filesystems.

The initramfs mounts the first set of FSes, so here is a patched version of that.

[hunger (hunger)]

mountkernfs.sh does some more...

[hunger (hunger)]

Then there is udev...

[hunger (hunger)]

Finally we need to update mtab.sh to report the new settings... mostly cosmetic...

[hunger (hunger)]

OK, that's it.

My system runs on those settings for about a day now. I have not run into trouble yet.

MORE TESTING IS REQUIRED of course:-)

[Martin Pitt (pitti)]

Tobias, I have some questions about /usr/share/initramfs-tools/init patch:

-mount -t sysfs none /sys
-mount -t proc none /proc
+mount -n -t sysfs -onodev,noexec,nosuid none /sys
+mount -n -t proc -onodev,noexec,nosuid none /proc

Why did you add -n? /sys and /proc are in /etc/mtab for me. However, at that point / should be readonly. So I understand that /etc/mtab is modified by /etc/init.d/mtab.sh, and the mount calls in initramfs cannot actually modify mtab? Scott, I would be glad for a confirmation here.

-mount -t tmpfs -o size=$tmpfs_size,mode=0755 udev /dev
-> /dev/.initramfs-tools
+mount -n -t tmpfs -o size=$tmpfs_size,mode=0755,noexec,nosuid udev /dev
+# > /dev/.initramfs-tools

-> same -n question; also, why did you comment out the /dev/.initramfs-tools stamp creation?

Please try to attach proper patches, not complete scripts. This makes it easier to review them and apply to other versions of the scripts.

The other patches look straightforward to me.

[Martin Pitt (pitti)]

installer is not actually affected, but initramfs-tools is.

[hunger (hunger)]

About sending in patches: Yes, I want to do that:-) The problem is that I start modifying and only when I am done I remember that I wanted to send a patch and do not have the original files around anymore...

About "-n": That option prevents mount from writing to /etc/mtab. Since / is mounted readonly at that point this seems sensible to me. If / is writeable already then adding -n does not hurt as /etc/init.d/mtab.sh will add the entry later. The init.d scripts do the same thing, so I assumed this was forgotten and added it.

About commenting out the timestamp: I commented it out mostly because I wasn't sure what that line is meant to do and ran into some trouble testing this stuff. I forgot to comment it in later.

Something else: I get a message along the lines of "/dev/zero can not be mmaped" at startup and shutdown and am not sure that this is related to my changes... serious testing of these changes is recommended.

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2006-08-09 at 07:01 +0000, Martin Pitt wrote:

> Tobias, I have some questions about /usr/share/initramfs-tools/init
> patch:
>
> -mount -t sysfs none /sys
> -mount -t proc none /proc
> +mount -n -t sysfs -onodev,noexec,nosuid none /sys
> +mount -n -t proc -onodev,noexec,nosuid none /proc
>
> Why did you add -n? /sys and /proc are in /etc/mtab for me. However, at
> that point / should be readonly.
>
No, at that point / is a memory filesystem (the initramfs) so it doesn't
make much of a difference whether -n is there or not because it's thrown
away at run-init time.

I would take out the "-n" to make debugging the initramfs easier (ie.
mtab makes sense there).

I'm not really sure what the point of the extra option is though; this
is a kernel virtual filesystem, it doesn't respect those options ANYWAY!
If the kernel wants to stick a setuid root binary, or device, in /proc;
a few mount options isn't going to stop it.

> -mount -t tmpfs -o size=$tmpfs_size,mode=0755 udev /dev
> -> /dev/.initramfs-tools
> +mount -n -t tmpfs -o size=$tmpfs_size,mode=0755,noexec,nosuid udev /dev
> +# > /dev/.initramfs-tools
>
Again the "-n" makes no sense, neither does the
"> /dev/.initramfs-tools" to me.

Why noexec or nosuid? I could understand being paranoid, but only root
can create files in /dev anyway.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2006-08-09 at 08:22 +0000, hunger wrote:

> About "-n": That option prevents mount from writing to /etc/mtab. Since
> / is mounted readonly at that point this seems sensible to me.
>
/ is not mounted at all at that point.

It worries me that you don't seem to understand the changes that you are
making.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2006-08-09 at 08:22 +0000, hunger wrote:

> Something else: I get a message along the lines of "/dev/zero can not be
> mmaped" at startup and shutdown and am not sure that this is related to
> my changes... serious testing of these changes is recommended.
>
Your mount options to /dev probably restrict access to mmap; I suspect
something is mapping /dev/zero with the option to execute it.

Scott
--
Scott James Remnant
<email address hidden>

[Matthew Garrett (mjg59)]

While the kernel can create files that ignore the mount options, I
believe that the behaviour is consistent with the rest of the vfs - that
is, a /proc mounted noexec will not allow files to be executed, even if
the kernel has created them with the execute bit. Having a noexec/nosuid
/proc was an acceptable workaround for one of the more recent Linux
kernel vulnerabilities, so there's a chance that it'll help avoid
future attacks.

The /dev case is more subtle. Vbetool mmaps /dev/zero, so is probably
what's getting upset there.
--
Matthew Garrett | <email address hidden>

[hunger (hunger)]

Yes, only the kernel may write to /proc and /sys. Yes, only root may write to /dev. If all is well and the kernel free of bugs then there is absolutely no need to do apply such restrictive mount options. In the real world it does not hurt to be paranoid IMHO: There was a recent vulnerability in the kernel that was exploitable on linux systems that had /proc mounted without nosuid.

I do not see how mounting /dev noexec,nosuid can cause trouble mmaping /dev/zero: That has mode 666 anyway and thus is not executable. In fact the only things having an executable bit set in /dev are directories and symlinks.

Scot is right of course: the real "/" is not used at all at this point in time, so it does not matter whether mount -n is used or not.

[Scott James Remnant (Canonical) (canonical-scott)]

You don't need the executable bit set on a file to be able to mmap it as executable

[Scott James Remnant (Canonical) (canonical-scott)]

Am rejecting this from udev ... it's been demonstrated that restricting the mount options for /dev causes problems.

[Scott James Remnant (Canonical) (canonical-scott)]

Made the appropriate changes in sysvinit to the filesystems

[Scott James Remnant (Canonical) (canonical-scott)]

Made the appropriate changes to /proc and /sys in initramfs-tools

[Jan (jan-de-haan)]

Comment on hunger's /etc/fstab, above.

sysfs /sys sys nodev,noexec,nosuid 0 0

should read

sysfs /sys sysfs nodev,noexec,nosuid 0 0

Please adjust, before someone else has to waste a couple of hours too on this little mistake.