<p dir="ltr">Isnt part of the idea behind kiss is security? And if you were to include selinux wouldnt you want to reduce that code as well?</p>
<div class="gmail_quote">On Oct 24, 2014 9:14 PM, "Rob Landley" <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 10/23/14 19:25, Andy Lutomirski wrote:<br>
> On Thu, Oct 23, 2014 at 5:21 PM, Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br>
>> On 10/16/14 20:17, Andy Lutomirski wrote:<br>
>>> Toybox's magical ability to present a usable shell without needing to<br>
>>> exec anything is almost perfect for poking around in a namespace.  The<br>
>>> only real missing piece is how to get into the namespace in the first<br>
>>> place.<br>
>><br>
>> Sorry for the delay on this one, you posted this before subscribing and<br>
>> I only clean out the spam filter infrequently. (There were about 50 spam<br>
>> and two good emails since last time.)<br>
>><br>
>>> Would it make sense to add some optional top-level command-line<br>
>>> options to enable this?  For example:<br>
>>><br>
>>> toybox --userns=/proc/whatever/user --uid=x --gid=y<br>
>>><br>
>>> Alternatively, if toybox were to implement nsenter and setpriv, it<br>
>>> would get this for free.  (I own copyright on a large portion of<br>
>>> setpriv, and I would be happy to relicense it.)  Then we could do:<br>
>>><br>
>>> toybox nsenter --whatever setpriv --whatever sh<br>
>>><br>
>>> and it might all just work.<br>
>>><br>
>>> Thoughts?<br>
>>><br>
>>> --Andy<br>
>><br>
>> I believe you already submitted nsenter (which I merged but got<br>
>> distracted halfway through cleaning up. I can probably finish cleanup<br>
>> this weekend). I don't remember setpriv, but it sounds like fun. (What<br>
>> does it do?)<br>
><br>
> setpriv is a low-level tool to read and change various Linux security<br>
> things.  It can set real/effective uid/gid, auxiliary groups,<br>
> inheritable caps, cap bounding set, securebits, selinux context,<br>
> apparmor context, and no_new_privs.<br>
<br>
I haven't done selinux or apparmor stuff in ls and cp and such. Adding<br>
it seems like a fairly extensive thing. (Not impossible: a compile time<br>
probe for "build environment has selinux support" and then a<br>
TOYBOX_SELINUX config thing, plus adding it to the various commands that<br>
would need it.)<br>
<br>
That said, I'm not really a fan of selinux: the NSA designed a system so<br>
complicated that you have to take the authors' word that this 50,000<br>
rule stack is actually doing soemthing useful. Post-Snowden, we actually<br>
_know_ they had projects to undermine cryptographic protocols and<br>
introduce backdoors to let them into systems and so on. But people still<br>
trust selinux. I don't understand why.<br>
<br>
Is there a consensus on whether or not we should go there?<br>
<br>
> Would anything blow up if xexec longjumped back to main?  Or what am I<br>
> missing here?  (Probably many things.)<br>
<br>
Memory leaks (just command line option parsing's going to allocate<br>
linked list structures and such, plus some of the pointers are to<br>
environment space and some to the heap and you have to distinguish to<br>
free 'em), filehandle leaks (O_CLOEXEC doesn't help if you didn't exec),<br>
signal handlers, mmap() if it did that, atexit() if it did that, you<br>
can't recapture suid once you've dropped it, setlocale() needs resetting<br>
(I think it handles that now?), process name (you can actually set that<br>
with prctl(PR_SETNAME))...<br>
<br>
Look at "man 2 execve" for a mostly but not quite complete list. (stuff<br>
like uname() and tty state are inherited by child processes anyway so<br>
even if you're going to exec you need to clean those up.)<br>
<br>
Mostly I worry about that sort of thing when trying to avoid exiting<br>
from the error_exit() path and instead doing a longjmp in xexit(). I<br>
have to do that for nofork commands, which are _mostly_ shell builtins<br>
but not necessarily entirely shell builtins?<br>
<br>
Something like 95% of the overhead of fork/exec is the exec part. Fork<br>
is cheap... when you have an mmu. :)<br>
<br>
Rob<br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div>