On 10/23/14 19:25, Andy Lutomirski wrote: > On Thu, Oct 23, 2014 at 5:21 PM, Rob Landley <[email protected]> wrote: >> On 10/16/14 20:17, Andy Lutomirski wrote: >>> Toybox's magical ability to present a usable shell without needing to >>> exec anything is almost perfect for poking around in a namespace. The >>> only real missing piece is how to get into the namespace in the first >>> place. >> >> Sorry for the delay on this one, you posted this before subscribing and >> I only clean out the spam filter infrequently. (There were about 50 spam >> and two good emails since last time.) >> >>> Would it make sense to add some optional top-level command-line >>> options to enable this? For example: >>> >>> toybox --userns=/proc/whatever/user --uid=x --gid=y >>> >>> Alternatively, if toybox were to implement nsenter and setpriv, it >>> would get this for free. (I own copyright on a large portion of >>> setpriv, and I would be happy to relicense it.) Then we could do: >>> >>> toybox nsenter --whatever setpriv --whatever sh >>> >>> and it might all just work. >>> >>> Thoughts? >>> >>> --Andy >> >> I believe you already submitted nsenter (which I merged but got >> distracted halfway through cleaning up. I can probably finish cleanup >> this weekend). I don't remember setpriv, but it sounds like fun. (What >> does it do?) > > setpriv is a low-level tool to read and change various Linux security > things. It can set real/effective uid/gid, auxiliary groups, > inheritable caps, cap bounding set, securebits, selinux context, > apparmor context, and no_new_privs.
I haven't done selinux or apparmor stuff in ls and cp and such. Adding it seems like a fairly extensive thing. (Not impossible: a compile time probe for "build environment has selinux support" and then a TOYBOX_SELINUX config thing, plus adding it to the various commands that would need it.) That said, I'm not really a fan of selinux: the NSA designed a system so complicated that you have to take the authors' word that this 50,000 rule stack is actually doing soemthing useful. Post-Snowden, we actually _know_ they had projects to undermine cryptographic protocols and introduce backdoors to let them into systems and so on. But people still trust selinux. I don't understand why. Is there a consensus on whether or not we should go there? > Would anything blow up if xexec longjumped back to main? Or what am I > missing here? (Probably many things.) Memory leaks (just command line option parsing's going to allocate linked list structures and such, plus some of the pointers are to environment space and some to the heap and you have to distinguish to free 'em), filehandle leaks (O_CLOEXEC doesn't help if you didn't exec), signal handlers, mmap() if it did that, atexit() if it did that, you can't recapture suid once you've dropped it, setlocale() needs resetting (I think it handles that now?), process name (you can actually set that with prctl(PR_SETNAME))... Look at "man 2 execve" for a mostly but not quite complete list. (stuff like uname() and tty state are inherited by child processes anyway so even if you're going to exec you need to clean those up.) Mostly I worry about that sort of thing when trying to avoid exiting from the error_exit() path and instead doing a longjmp in xexit(). I have to do that for nofork commands, which are _mostly_ shell builtins but not necessarily entirely shell builtins? Something like 95% of the overhead of fork/exec is the exec part. Fork is cheap... when you have an mmu. :) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
