[Toybox] Using toybox for poking around weird namespaces?

[Rob Landley]

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

 1414298886.0