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 <[email protected]> wrote: > On 10/25/14 11:00, Andy Lutomirski wrote: > > On Oct 24, 2014 6:14 PM, "Rob Landley" <[email protected]> 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 >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
