[Toybox] Using toybox for poking around weird namespaces?

[Kenton Varda]

FWIW, Andy and I are mainly interested in extending toybox for use as a
tool for debugging Sandstorm.io apps. Sandstorm does not use selinux. In
fact, Sandstorm is fundamentally opposed to selinux. :)

setpriv does many other useful things, like setting the uid/gid and
enabling no_new_privs, which we do want.

On the topic of exec: we are interested in toybox specifically because it
has the ability to run builtin commands without re-execing itself. This
makes it useful for poking around inside a namespace where the toybox
binary isn't actually visible in the filesystem (and /proc isn't mounted).
So we would actually want to disable the recursion counter.

(Maybe some sort of tail recursion optimization makes sense here?)

-Kenton

On Sat, Oct 25, 2014 at 9:48 PM, Rob Landley <rob at landley.net> wrote:

> On 10/25/14 11:00, Andy Lutomirski wrote:
> > On Oct 24, 2014 6:14 PM, "Rob Landley" <rob at landley.net> wrote:
> >>>> 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.
>
> The security settings are stored in extended attributes, right?
>
> Sigh. I suppose making cp/mv support extended attributes would also help
> with kvm's virtfs (which uses them on the host)...
>
> Do I actually have to care about selinux itself, or will copying the
> extended attributes do it? No, if selinux is enabled on the host it'll
> force you to access the extended attributes _through_ the security
> infrastructure, won't it?
>
> (I very, very vaguely remember reading this code when I maintained
> busybox. Eight years ago.)
>
> >> 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?
>
> I'm pretty happy with that. That said, setpriv has this feature. Is
> setpriv useful _without_ this feature?
>
> >> 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.
>
> That's more or less the general idea of any shell: toysh keeps itself
> clean, calls fork, and has the child processes do the strange bits. You
> don't have a dedicated zygote, the parent process _is_ the zygote.
>
> There are various cases like the umask builtin and exec redirects where
> you modify the state of the current shell and it is inherited by the
> child processes. You _need_ to have these changes inherited by children,
> so you'd have to impose them upon a "zygote" cross-process, which isn't
> fun.
>
> (Heck, exported environment variables are inherited by child processes,
> the "VAR=VALUE commandname" stuff just does the fork first and does the
> exports in the child so the parent shell's environment is affected. You
> can do all sorts of stuff in the child (after the fork) before launching
> the command, and it goes away when the child does. The problem with this
> is vfork() on nommu systems, but a "zygote" doesn't really help there.)
>
> A shell has to be implemented as a long-running program just like a
> webserver. It's designed around keeping track of its state and not
> leaking resources, but its state isn't entirely static either.
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20141025/e1deac2c/attachment-0002.htm>