On Oct 24, 2014 6:14 PM, "Rob Landley" <[email protected]> wrote: > > > > 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.)
True. Setpriv takes the minimal approach: no libraries or translation, just raw settings. I only did it because I wanted to try to cover as many relevant security settings as I could. > > 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? Wait until there's actual demand? > > > 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. :) I suppose that toysh could do it zygote style: fork once at or soon after startup, and then, as needed, fork new processes off the clean forked child. --Andy > > Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
