I think the trick is not to run the processes in the chroot as root. I used a command like this (as root)
/usr/sbin/chroot chroot_directory su - sage -c "sage -c \"$COMMAND\" " Thus the sage process inside the chroot is run by a user "sage". I am not sure how secure this is. Any ideas? Michel On Oct 5, 8:45 pm, [EMAIL PROTECTED] wrote: > This was posted to slashdot sometime last week: > > http://kerneltrap.org/Linux/Abusing_chroot > > The gist: root can trivially break out of the chroot "jail" -- and is then > the superuser on the system. I'm not a security expert, but this sounds only > locking the driver's door of a car, and leaving a key on the dash: if a user > can escalate to root in the jail, they root the box. > > Another slashdot article today made me think about this again: > > http://computerworld.co.nz/news.nsf/scrt/CD0B9D97EE6FE411CC25736A000E... > > Sure, windows is insecure. But n00bs like me doing security is insecure no > matter what operating system they use. If the notebook isn't secure, and > Sage achieves the BDFL's primary goal, then we'll become a major contributor > to the online efforts of organized crime and spam. > > So: what can we use instead? VMWare? UML? SELinux in VMWare running under > UML? Or, will we have to stop executing arbitrary code by unknown public > entities again? (I really hate the last option) --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
