On Sat, Mar 05, 2005 at 06:30:55PM +0100, Blaisorblade wrote: > On Thursday 03 March 2005 02:17, nils toedtmann wrote: > > On Wed, Mar 02, 2005 at 12:35:23PM -0800, Jim Carter wrote: > > > On Wed, 2 Mar 2005, Maarten wrote: > > > > Out of curiosity, is a 'default' SKAS-enabled guest (and without the > > > > host-fs kernel option) safe enough as a sandbox to let untrusted users > > > > in, or are additional measures in order to really secure it (or more > > > > paranoia ;-) ? Ie. how difficult is it to gain access to the host OS > > > > from the UML guest? > > > > > > Here's my take on the issue. Do other list members have additional or > > > contravening insights? > > > > > > If a very sharp hacker "gets root" on the UML guest, he can overwrite the > > > kernel any way he pleases, executing arbitrary code as the UML special > > > user. If he finds himself in a chroot jail, he can import statically > > > linked tools (using ports that have to be open for the guest's mission) > > > and perpetrate the same 'sploit against the host. The jail makes this > > > harder but not impossible. > > > So if there's an exploit in the wild against your kernel version, UML > > > won't save you. > > > > [...] > > > > You can harden the chroot (mount it ro,noexec,nodev, bindmount > > uml-binary as the only executable into it, bindmount /dev/net/tun > > as the only device, mount tmpfs noexec,nodev).
Unfortunatly, i am mistaken: "Checking PROT_EXEC mmap in /tmp...failed: Operation not permitted /tmp must be not mounted noexec" But instead, you can 'umount -l' (lazy umount, somebody sug- gested this during the cannot-umount-tmpfs-after-shutdown discussion) /tmp right after booting such that it is unusable. Then there is no writable place in the chroot left besides image/cow-files. The attacker could overwrite them, but uml won't like that ... > Hmm, nice list... only one problem I guess. > 1) you forgot to bindmount /proc/mm Of course! And if you want to have persistant filesystem images or CoW files, same goes for them. Otherwise, put the CoW files on the tmpfs. Older uml needed /proc/cpuinfo (at least due to my experiments with chroot), but that need seems to have been silently removed. As /proc/mm is 222: what harm could an attacker do by writing into /proc/mm? > Except for that, the more I read this list, the more I like it. ;-) > It's impossible to get the chroot noexec if you don't bindmount uml-binary, > and the same for nodev and tun. yepp. The only problem is that you get at least 5 mounts in your mounttable per uml, that can get confusing on a host with bunches of umls >:-o (you could use 'mount -n') > Only thing to note about that is that /dev/net/tun is useful only if you > install uml_utilities, including uml_net, inside the chroot (but you won't, > right)? No. I do tuntap without any utilities, and that needs /dev/net/tun inside the chroot, too. Otherwise i get a "Failed to open /dev/net/tun, err = 2" (just tested to be sure ;-) To sum it up, this temporary chroot works-for-me[tm]: mkdir chroot mount -t tmpfs -o size=1k,mode=750,gid=uml,nodev,nosuid,noexec none chroot mkdir chroot/tmp mount -t tmpfs -o size=129M,mode=770,gid=uml,nodev,nosuid none chroot/tmp/ mkdir -p chroot/proc chroot/dev/net touch chroot/proc/mm chroot/dev/net/tun chroot/linux chroot/rootfs mount -o bind /proc/mm chroot/proc/mm mount -o bind /dev/net/tun chroot/dev/net/tun # has to be rw for (g)id=uml mount -o bind ubd/FC3-rootfs.ext3 chroot/rootfs # has to be rw for (g)id=uml mount -o bind boot/linux-2.6.9-bb4-terminal-cleanup-nils9 chroot/linux # has to be x for (g)id=uml mount -o remount,ro chroot/ screen -S uml /usr/bin/compartment --user uml --group uml --chroot chroot /linux umid=uml mem=128M uml_dir=/tmp con=null con0=null,fd:2 con1=fd:0,fd:1 eth0=tuntap,tap00,FE:FD:00:DE:AD:06 ubd0=/rootfs devfs=nomount sleep 10 umount -l chroot/tmp Maybe you could 'umount -l' chroot/dev/net/tun & chroot/rootfs, too? Or are they re-opened during operation like chroot/linux? After shutdown, destroy the chroot: umount chroot/linux chroot/rootfs chroot/dev/net/tun chroot > > Then the method you > > mentioned (injecting static code into the uml kernel) is the only > > way to run code inside the chroot. That's hard, and a small mis- > > take will result in a smashed uml kernel, but it can be done > > (there are articles on phrack magazine which claim that). Using > > additional kernelpatches like openwall or grsecurity may prevent > > that, but i don't know if they work on ARCH=um (i know that LIDS > > works with a tiny patch). > > Sooner or later, we'll get them (at least the more important ones) ported. > SELinux is in the tree and is supported fully (there's an howto on this on > the community site IIRC). What helps is "um" being an official architecture in 2.6 now. /nils. -- there is no sig. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
