Wilders Security Forums  

Go Back   Wilders Security Forums > Software, Hardware and General Services > all things UNIX
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
 
Thread Tools Search this Thread
  #1  
Old April 28th, 2012, 01:02 AM
Gullible Jones
 
Posts: n/a
Default 'mount -o bind' behavior is broken on Linux. Fixes? Workarounds?

Those of us who have messed around with 'mount -o bind' know that 'mount -o bind,ro' sounds good in theory, but doesn't work in practice.

Code:
# mount -o bind,ro /dev foo mount: warning: foo seems to be mounted read-write.

You can of course always do mount -o remount,ro. But this is rather inconvient.

However... It turns out that things are even more broken than that. 'mount -l' lists mount flags such as noexec and nosuid as being applied, even though they are actually ignored. Observe:

Code:
# mount -l /dev/root on / type ext4 (rw,noatime,barrier=1,data=writeback) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) /dev/sda3 on /home type ext4 (rw,noatime,data=writeback) tmpfs on /dev/shm type tmpfs (rw) /bin on /sandbox/bin type none (rw,nosuid,bind) /sbin on /sandbox/sbin type none (rw,nosuid,bind) /usr on /sandbox/usr type none (rw,nosuid,bind) /dev on /sandbox/dev type none (rw,nosuid,bind) /proc on /sandbox/proc type none (rw,nosuid,bind) /sys on /sandbox/sys type none (rw,nosuid,bind) /etc on /sandbox/etc type none (rw,nosuid,bind) /var on /sandbox/var type none (rw,nosuid,bind) /tmp on /sandbox/tmp type none (rw,nosuid,bind) /lib on /sandbox/lib type none (rw,nosuid,bind) # chroot --userspec=USERNAME /sandbox /bin/bash $ su - Password: No directory, logging in with HOME=/ # whoami root

Nice little "gotcha" there. Are there any workarounds for this, short of setting up a boot script to remount everything? Any patches to the kernel to fix this? How long has this situation existed?

Last edited by Gullible Jones : April 28th, 2012 at 01:02 AM. Reason: This issue is limited to Linux as far as I know.
  #2  
Old April 28th, 2012, 05:12 PM
Gullible Jones
 
Posts: n/a
Default Re: 'mount -o bind' behavior is broken on Linux. Fixes? Workarounds?

Update: an explanation of why this won't work. But note that Debian includes a patch to make "mount --bind -r" create a read-only bind mount. Yay Debian, I guess... Though I do wonder why that patch hasn't been included upstream.

As for workarounds, there is apparently one, at least for Fedora 14, that involves paired entries in fstab. IMO this is even uglier than creating an initscript... I think I'll pass.

BTW, the situation oddly seems to be better on Linux (which at least supports bind mounting, if in a half-broken fashion) than on the famously paranoid OpenBSD (which doesn't support the BSD equivalent, mount_nullfs, any more).

Edit: Hmm, maybe the feature is missing from OpenBSD because it can create problems? I've already happened across some interesting cases where bind-mounted directories cannot be unmounted, despite nothing technically accessing their contents. OTOH, symbolic links are useless for this purpose... So what's the alternative? Is there one?

Last edited by Gullible Jones : April 28th, 2012 at 05:26 PM.
  #3  
Old April 28th, 2012, 06:14 PM
Gullible Jones
 
Posts: n/a
Default Re: 'mount -o bind' behavior is broken on Linux. Fixes? Workarounds?

Hmm. It seems there is an alternative for BSD, if you have portmap or rpc enabled...

Code:
mount -t nfs -o ro,nosuid localhost:/somepath /some/other/path

Not sure about the security implications of that though (and I'm having trouble getting it working on Linux).
 

Wilders Security Forums > Software, Hardware and General Services > all things UNIX « Previous Thread | Next Thread »

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Settings
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -4. The time now is 07:07 PM.


Powered by vBulletin® Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©2002 - 2013, Wilders Security Forums