<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 19, 2015 at 9:31 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Looking at the smack-10 tree ala:<br>
<br>
commit cbc95a1a00ae0a1a806e7cc241cdf7b821ee4951<br>
Author: José Bollo <<a href="mailto:jose.bollo@open.eurogiciel.org">jose.bollo@open.eurogiciel.org</a>><br>
Date: Mon May 11 18:53:12 2015 +0200<br>
<br>
mkdir: Add -Z option<br>
<br>
Specifically this bit:<br>
<br>
- for (s=toys.optargs; *s; s++)<br>
+ for (s=toys.optargs; *s; s++) {<br>
if (mkpathat(AT_FDCWD, *s, mode, toys.optflags|1))<br>
perror_msg("'%s'", *s);<br>
+ else if (CFG_MKDIR_SECURITY && (toys.optflags & FLAG_Z)) {<br>
+ if (security_set_context(*s, TT.arg_context) < 0) {<br>
+ rmdir(*s);<br>
+ error_exit("Unable to create directory '%s' with '%s' as<br>
context.", *s,<br>
+ }<br>
+ }<br>
+ }<br>
<br>
Isn't this racy? You create the directory without a label, then come along<br>
at some arbitrary point later and add one? Shouldn't we at least mkpathat()<br>
with mode 000, add the label, and then chmod()?<br></blockquote><div><br></div><div>i don't know if this is the least worst job you can do with SMACK, but this isn't how you'd do it with SELinux. you'd call setfscreatecon before the mkdir, so there would be no race. call it again with NULL afterwards to go back to the default.</div><div><br></div><div>(note that i'm not actually an SELinux expert. i just play one on this mailing list. but i've seen this done in other code by people who do know what they're doing.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Or does it not work that way with this stuff? (I dunno if we can add a label<br>
to a directory we can't write to. I dunno we can chmod it after we've stuck<br>
a label on it. Maybe the race condition is inherent in the design because<br>
Stewart's bosses were more interested in gaining perpetual access to<br>
everybody's infrastructure than actually securing it?)<br>
<br>
Also, I take it setcontext still isn't setting errno to anything useful?<br>
Sigh. These are very rough-edged APIs. Nobody's ever gone through to clean<br>
them up on the kernel side. (I dunno if this is the same "How dare newbies<br>
like you look through openssl to find heartbleed? Keep your ignorant paws<br>
off our magic code mortals are not meant to understand" thing as the crypto<br>
world, or if it's just nobody who isn't being paid to work on this cares<br>
about this bureaucratic infrastructure for filling out forms in triplicate.<br>
Possibly a combination of the two.)<br>
<br>
Oh, don't error_exit() in the middle of looping on optargs, just error_msg()<br>
and that'll set toys.exitval to 1 if it's not already set to a nonzero value<br>
so when we _do_ exit it returns an error value. Otherwise you don't process<br>
the full list, and you're supposed to.<br>
<br>
Rob<br>
<br>
P.S. I suspect I have slightly more sympathy for smack than for other Linux<br></blockquote><div><br></div><div><aside></div><div>you know, if you spent as much time actually digging into this stuff as you did ranting about it, you'd find that it's _very_ effective in practice :-)</div><div><br></div><div>SELinux demonstrably mitigates most of the classes of old Android exploits. that is, even if you reintroduce the bugs that were in old versions of Android, SELinux makes them non-expolitable.</div><div><br></div><div>it may not be pretty, but in the real world, mitigation is the best defense. and, yes, you can screw up your use of the primitives [like with this attempt at mkdir -Z] or you can screw up your security policies [that is, allow things that shouldn't be allowed], but there's no question that centralized policies are significantly more auditable than "all the code that makes up the platform, plus every piece of OEM code, plus every piece of third-party code you can install or sideload".</div><div><br></div><div>is it perfect? of course not.</div><div><br></div><div>are users significantly better off because of it? yes, no question about it.</div><div><br></div><div>and you don't have to trust the NSA --- you can show us where the backdoors are. all this code is open source. none of this relies on any kind of secret TPM stuff you're not allowed to look at.</div><div><br></div><div>i initially had the same knee-jerk "why do we need all this new-fangled crap? i never needed it in the 1990s" reaction, and i still don't need it on my development desktop, but in the hostile world of random unsophisticated users downloading and executing arbitrary code it's absolutely necessary.</div><div><br></div><div>...</div><div><br></div><div>at the risk of encouraging you, what you *should* be worried about is the inherent tension with all this security stuff of the difference between "good for users" and "good for developers" :-)</div><div></aside></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Sado-Masochism plugins because at least they're not using "security"<br>
infrastructure developed by the NSA _after_ the Snowden revelations*. Then<br>
again rolling your own security seems like rolling your own crypto, so...<br>
Either way I still consider this stuff mostly for show, as in the "S" in<br>
the middle of TSA, NSA, and LSM all have the exact same meaning as far as<br>
I'm concerned, and are of about as much real-world use.<br>
<br>
But I'm trying very hard not to let this influence my technical judgement.<br>
"I am not the target audience for this infrastructure, and the people who<br>
need it care deeply about it." (Whether what they need it for is to<br>
placate middle management or justify budgetary expenditures or show nominal<br>
compliance with a bureaucratic standard is none of my business: they<br>
can't deploy the software without it. "Something must be done, this is<br>
something, therefore we must do it.")<br>
<br>
On the one hand, it doesn't seem to be important to its target audience<br>
whether it actually _works_ (as long as it _seems_ to work). On the other<br>
hand, if toybox is going to have infrastructure I want it to be the best<br>
version of that infrastructure it can be. If we're gonna do it, we do it<br>
right.<br>
<br>
Alas, all my instincts say that doing it right in this case involves not<br>
going there in the first place, and we've already burned that bridge, so<br>
there's a certain amount of "flying blind on a rocketcycle"** going on here.<br>
I do not know how to fix this, on at least two levels.<br>
<br>
* I can't remember if those were in Leviticus or Deuteronomy. Something<br>
about nine-bladed flaming swords with root access.<br>
<br>
** It's a BRIAN BLESSED reference. It was the 80's. Queen was involved.<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><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Elliott Hughes - <a href="http://who/enh" target="_blank">http://who/enh</a> - <a href="http://jessies.org/~enh/" target="_blank">http://jessies.org/~enh/</a><br>Android native code/tools questions? Mail me/drop by/add me as a reviewer.</div>
</div></div>