switch_root and mount move

Sergey Naumov sknaumov at gmail.com
Wed May 2 18:06:07 UTC 2012


> Oh dear, "security".

> You're aware you can break out of a simple chroot and get back into the
> initramfs, right?

As I understood from your own description in switch_root.c, you are
calling chdir("/") to prevent such an ability.
Can an attacker break out from this chroot (applet called from bash,
not a chroot() system call in a C program)?

> I'm still unclear on what you're trying to do.
I am trying to call rsbac_init in initramfs (so as soon as possible)
with acl set up for /dev/sda2 (my root device) which prohibits its
mounting/remounting (the only way to disable remount in rsbac is to
disable mount), but as long as original switch_root (which has to be
the last statement in initramfs ) is using mount() call on root to
move it from /newroot to /, initialized rsbac prohibits this call and
it leads to a kernel panic (It is strange for me too that rsbac treats
mount with MOVE flag like regular mount).
I can use chroot applet, but also I want to clean initramfs content,
so with -m option switch_root cleans initramfs and then performs the
same thing as chroot applet (chroot(newroot); chdir("/")), but does it
"atomically".

> So you haven't noticed any changes in behavior, except for this change
> in behavior...
I wanted to say that my system remains operable, but with additional
25Mb of free memory.
The only thing I haven't tested is a necessity of mount -o move /proc
/newroot/proc && mount -o move /sys /newroot/sys calls which I have
added after reading a switch_root manual. It says that switch_root
mounts these filesystems on the new root. May be it does it by mount
move. So I say that I am using swich_root -m as a chroot applet, but
with a benefit of freed initramfs memory.

Sergey Naumov.


More information about the busybox mailing list