Re: switch_root and mount move
On 2 мая 2012 12:01:49 Rob Landley wrote: I repeat: I have no clue what you're trying to accomplish here. Shortly: immutable read-only rootfs. Which RSBAC can provide with proper rule set (and the rule set can be prevented from changing by rsbac_freeze). ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: switch_root and mount move
On 05/03/2012 03:52 AM, Roman Khimov wrote: On 2 мая 2012 12:01:49 Rob Landley wrote: I repeat: I have no clue what you're trying to accomplish here. Shortly: immutable read-only rootfs. I've used squashfs, isofs, cramfs, and romfs. None of them are so immutable that mount --move doesn't work. Which RSBAC can provide with proper rule set (and the rule set can be prevented from changing by rsbac_freeze). You're trying to protect the operating system from the root user. This is the part that seems crazy at a conceptual level. Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's mere aggregation, or a license violation. Pick one. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: switch_root and mount move
On 3 мая 2012 11:26:55 Rob Landley wrote: On 05/03/2012 03:52 AM, Roman Khimov wrote: On 2 мая 2012 12:01:49 Rob Landley wrote: I repeat: I have no clue what you're trying to accomplish here. Shortly: immutable read-only rootfs. I've used squashfs, isofs, cramfs, and romfs. None of them are so immutable that mount --move doesn't work. Well, that kind of immutability doesn't work for us for several reasons, let's say there are times (like special boot modes) when we do need to write something to rootfs in a normal way. To reboot then in normal operating mode with that rootfs locked up again. Thus the original question with 'mount --move' --- when we load up RSBAC rule that prohibits remounting rootfs original switch_root stops working because of 'mount --move' failure. Which RSBAC can provide with proper rule set (and the rule set can be prevented from changing by rsbac_freeze). You're trying to protect the operating system from the root user. This is the part that seems crazy at a conceptual level. RSBAC allows us to make root a bit less root than usual and we do want that additional level of protection. It's not to say that it's the only way we protect our system, but that is an additional level for sure. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: switch_root and mount move
I have implemented a patch which adds -m option to switch_root which prevents it from making a mount-move. I haven't noticed any changes in behavior of my system, but now I can do all necessary mounts in initramfs, then call rsbac_init as last but one statement (after that any mount call for root device would fail) and then call switch_root -m /newroot /sbin/init. So I have a chroot behavior, but also can benefit from switch_root's cleaning of initramfs content. It sounds like you're saying you _don't_ want to let people do mount --remount,rw /, that with the current switch_root you can and with your proposed modification you can't? Without -m option I would be reluctant to defer rsbac initialization to later boot stages and it is not so good in terms of security, I think. If anybody interested in, I can send this patch. Sergey Naumov. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: switch_root and mount move
On 04/25/2012 08:28 AM, Sergey Naumov wrote: Hello. Could anyone explain what is the purpose of mount move in switch_root? From this answer (http://lists.busybox.net/pipermail/busybox/2009-June/069609.html) I got reasons why we need to make chroot AND chdir, but can we do it without mount move? The intent was to line up the system view of the mount tree with reality, but these days chroot() itself does some of that adjustment (it didn't used to). I remember testing various corner cases of this and that was needed to get the right behavior out of _something_, but it was more than 5 years ago. If you don't need it, you don't need it. A quick glance at the util-linux switch root implementation shows that they're doing the mount(MS_MOVE) too, but they could easily have copied that from me. :) (Am I allowed to track down the github developers who implemented some horrible java animation for switching pages and play Weird Al's bohemian polka at them in a loop until they promise to yank it out and never do it again? *shudder*) My problem is that I want to disable ability to remount root to rw by rsbac, but I need to call rsbac_init in initramfs after all necessary mounts are done, so at the time switch_root is called mounting/remounting of root device is prohibited. Simple chroot works, but I want to clean initramfs content too. It sounds like you're saying you _don't_ want to let people do mount --remount,rw /, that with the current switch_root you can and with your proposed modification you can't? That sounds like exactly the sort of thing this would be aimed at... Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's mere aggregation, or a license violation. Pick one. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: switch_root and mount move
On 05/02/2012 11:21 AM, Sergey Naumov wrote: I have implemented a patch which adds -m option to switch_root which prevents it from making a mount-move. If the mount move isn't needed, it shouldn't do it. If it is needed, it should do it. Providing a knob to control something 99.9% of the userbase have no idea even _exists_ seems less than ideal. I haven't noticed any changes in behavior of my system, but now I can do all necessary mounts in initramfs, So you haven't noticed any changes in behavior, except for this change in behavior... I'm still unclear on what you're trying to do. then call rsbac_init as last but one statement (after that any mount call for root device would fail) and then call switch_root -m /newroot /sbin/init. So I have a chroot behavior, but also can benefit from switch_root's cleaning of initramfs content. So you do something funky to make your filesystem immuntable, and this prevents a mount --move from working on it. Which is really weird because mount --move is a vfs option, not a filesystem option. It sounds like you're saying you _don't_ want to let people do mount --remount,rw /, that with the current switch_root you can and with your proposed modification you can't? Without -m option I would be reluctant to defer rsbac initialization to later boot stages and it is not so good in terms of security, I think. Oh dear, security. You're aware you can break out of a simple chroot and get back into the initramfs, right? Dunno why you'd want to, but in C it's something like: mkdir(sub, 0700); chroot(sub); chdir(../../../../../../../../..); chroot(.); Congratulations, you're in initramfs. Because the kernel's chroot test is for equality, not = (which isn't a relationship dentries really _have_ anyway), so if you move it below your current directory you can ascend all the way to the root of the tree. Even if you've deleted everyting out of it, initramfs is still writeable to root. I repeat: I have no clue what you're trying to accomplish here. Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's mere aggregation, or a license violation. Pick one. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: switch_root and mount move
On 05/02/2012 12:06 PM, Cathey, Jim wrote: mkdir(sub, 0700); chroot(sub); chdir(../../../../../../../../..); chroot(.); If that works, the kernel is broken IMHO. Or is this predicated on the CWD not being somewhere in the chroot path to begin with? -- Jim Yes, chroot is broken. If you're root, you can break out of a chroot. http://landley.net/notes-2011.html#02-06-2011 I've had a todo item to fix this for most of a year now, but it's a couple weeks work and competes with 800 other todo items... Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's mere aggregation, or a license violation. Pick one. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: switch_root and mount move
mkdir(sub, 0700); chroot(sub); chdir(../../../../../../../../..); chroot(.); If that works, the kernel is broken IMHO. Or is this predicated on the CWD not being somewhere in the chroot path to begin with? -- Jim ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: switch_root and mount move
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. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: switch_root and mount move
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)? Same thing. If you can do it in C, you can do it in shell. It takes a few lines of C code to write the following programs: * opendir fd dir remainder performs an opendir() system call on dir, assigns the result to the fd file descriptor, and execs into remainder. * fchrootdir fd remainder performs fchdir(fd), close(fd), chroot(.) and execs into remainder. Then breaking out of a chroot is a breeze: Say A is the script that runs under a chroot. Instead of writing chroot /newroot A, you write opendir 3 / chroot /newroot fchrootdir 3 A and A will execute under the old root, despite the chroot command. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
