[Toybox] Using toybox for poking around weird namespaces?

[Rob Landley]

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.)

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

 1414199688.0