[Toybox] Using toybox for poking around weird namespaces?

[Andy Lutomirski]

On Oct 24, 2014 6:14 PM, "Rob Landley" <rob at landley.net> wrote:
>
>
>
> On 10/23/14 19:25, Andy Lutomirski wrote:
> > On Thu, Oct 23, 2014 at 5:21 PM, Rob Landley <rob at landley.net> 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

 1414252810.0