[Toybox] Adding LSM support to mkdir.

[Rob Landley]

On Thu, May 28, 2015 at 11:55 AM, enh <enh at google.com> wrote:
>
>
> On Tue, May 19, 2015 at 9:31 PM, Rob Landley <rob at landley.net> wrote:
>>
>> Looking at the smack-10 tree ala:
>>
>>   commit cbc95a1a00ae0a1a806e7cc241cdf7b821ee4951
>>   Author: José Bollo <jose.bollo at open.eurogiciel.org>
>>   Date:   Mon May 11 18:53:12 2015 +0200
>>
>>       mkdir: Add -Z option
>>
>> Specifically this bit:
>>
>>   -  for (s=toys.optargs; *s; s++)
>>   +  for (s=toys.optargs; *s; s++) {
>>        if (mkpathat(AT_FDCWD, *s, mode, toys.optflags|1))
>>          perror_msg("'%s'", *s);
>>   +    else if (CFG_MKDIR_SECURITY && (toys.optflags & FLAG_Z)) {
>>   +      if (security_set_context(*s, TT.arg_context) < 0) {
>>   +        rmdir(*s);
>>   +        error_exit("Unable to create directory '%s' with '%s' as
>> context.", *s,
>>   +      }
>>   +    }
>>   +  }
>>
>> Isn't this racy? You create the directory without a label, then come along
>> at some arbitrary point later and add one? Shouldn't we at least
>> mkpathat() with mode 000, add the label, and then chmod()?
>
> 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.

Hmmm... ctrl-alt-google "what is the smack equivalent of
setfscreatecon" and apparently it's called smack_set_label_for_self().

Good to know. I'll try that then.

(Last night got eaten taking yet another look at boxes because crisis.
Shortly before that my house flooded again, but I'm in Japan this time
so merely stressed rather than personally experiencing FanPocalypse
II: The Re-Blowing. "This time, it's probably going to involve
landscaping.")

> <aside>
> 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 :-)

I've actually spent more time studying it as ranting about it, but
most of it wasn't recent.

I am trying to make this work, but this involves trusting other people
who don't see it as inherently completely toxic to tell me what to do.

My first bad experience with selinux was trying to read through Red
Hat Enterprise's selinux ruleset when I had to use an selinux-based
system several years ago (I'm going to guess "R-HELL 2" but it was a
while ago) and coming to the conclusion that human beings not being
able to understand the tens of thousands of interlocking rules was an
explicit design goal on the part of _somebody_.

Maybe somebody else fought back since. Dunno.

> 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.

I believe that selinux prevents code from running, yes. It's very good
at preventing code from running. In my experience, that includes (at
least) any code not designed around SELinux in the first place.

That's part of the reason my 2013 talk treated dalvik (now ART) as the
domed city of Android, outside which was naught but a post-apocalyptic
wasteland. It wasn't just the lack of supportive infrastructure, it
was the presence of actively toxic forces, at least in the default
configuration.

In 2012 I sat down with a co-worker who'd bought an android tablet and
had followed some online instructions to get a shell prompt, and
wanted me to show them how to do something really trivial with it. (I
forget what. Install busybox? Get it to copy files off of a usb key?
Something along those lines. Five minute job on a conventional Linux
PC.)

We spent something like 6 hours before giving up. Fighting selinux
every minute of that. This is where I learned "every process is
running as a seperate userid, isn't it?" and "I hexedited the darn
filesystem to give me an suid root binary, forced it to mount without
things like nosuid, rebooted into android and root can't even do as
much as the non-root user process? What the...")

Meanwhile the embedded systems we put together at $DAYJOB were based
off of our employer's fork of TI's fork of android's fork of linux,
with android and posix userspaces installed alongside each other, and
both contexts worked great. The difference? On these devices, selinux
was never on. (It would break the app the device existed to run.)

> 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],

That's not the only failure mode. The most secure system in the world
is switched off, crushed, dissolved in acid, and the remains buried in
a sea trench. By this metric, selinux is very good at securing
systems.

I have a dream that smartphones can someday replace PCs, but PCs can't
go away until "you can't do that here, you need to use a real computer
instead" stops being a failure condition selinux regularly imposes
upon android.

I have no idea how to go about that, so I'm focusing on filling in
missing infrastructure. I trust you guys will eventually figure out
how to tame your own self-imposed hairshirt.

> 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".

Mainframes were totally auditable too. You could prevent anybody from
doing anything. Having to badge into the room to get access to the
machine in the first place helped.

> is it perfect? of course not.
>
> are users significantly better off because of it? yes, no question about it.

I agree that ipad-style read only consumers of a locked-down device
primarily used to watch netflix, tweet, and play tower defense games
(or using only approved apps to author content such as emails) are not
negatively impacted by selinux.

I also agree that having a keylogger when you check your bank account
balance is a significant downside requiring equally significant
preventive measures.

> 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.
>
> i initially had the same knee-jerk "why do we need all this new-fangled
> crap? i never needed it in the 1990s" reaction,

The same way we didn't used to need to tap everybody's phone for the
government to function? There were governments at the time that _did_
do that. Most of 'em went away...

> and i still don't need it on my development desktop,

Except I'm trying to get android to the point it can replace
development desktops.

Does "don't need it" mean "it's not worth it" and does that mean "it's
significantly better not to have it" and then "_how_ significantly
better", and then what is that traded off against, and then who
qualifies as a representative sample and representative of what...

> but in the hostile world of random unsophisticated
> users downloading and executing arbitrary code it's absolutely necessary.

As I said in my talk, a billion unadministered broadband connected
machines is terrifying.

I _am_ adding -Z support. I'm not arguing you shouldn't be using
selinux today, certainly not after the fact when it's the law of the
land for years now. If nothing else, you're stuck with it to support
your installed base.

(Although a chroot with posix semantics would be nice: I understand
containers. I do not understand selinux. Adapting AOSP to run to
completion on a stock android host is gonna be _so_ much fun...)

> 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" :-)

That's too simplistic. Add a "perceived as good" vs "actually good"
category on both sides, and then substitute those for tradeoffs of
things with plusses and minuses along a dozen major axes that fight...

The magnitude of the problem is not an endorsement of any specific
solution to that problem. SELinux is not an elegant solution to
anything. I expect a more elegant solution to emerge eventually,
probably looking more like containers than SELinux, at which point the
installed base of SELinux becomes an impediment to fixing things
properly.

But what else is new?

I'm in japan right now, which had a tsunami that convinced them to
stop using nuclear power so they massively increased fossil fuel
imports and it's bad choices wherever you turn but the lights are on
anyway. They also had several cases of malaria transmission in a park
here last summer (some visitor had it and the mosquitoes got it, and
there's probably a wildlife resovoir), and in the USA we had horrible
malaria for centuries until we wiped it out with DDT in the 1940's,
wiping out the Bald Eagle from the lower 48 at the same time. Was that
a net positive? Proooobably? Does that mean Japan should spray tokyo
down with DDT while I'm here so this new outbreak doesn't get to
spread? I'd rather they didn't?

I'm familiar with double edged swords and hard problems with no good
solution and a whole lotta interlocking side effects. I've clearly put
selinux in the "DDT and radiation" category of things I'd really
rather not get on me personally, yet here we are in a thread about
making it work.

I also throw selinux in an adjacent bucket to decss. There's an aspect
of "they meant well" with selinux that DVDCCA didn't have, but people
who hit region locking go off and do streaming instead so you mostly
don't hear about them. Blu-ray's problem was "lack of uptake" relative
to all the streaming services (such as bittorrent). These sort of
restrictions tend to be self-limiting in the long run because they are
coincidentally replaced by things that work out how not to do that.

I dunno if raspberry pi at $25 changes anything (probably not, you
could airdrop 'em on desert villages and it still needs peripherals
and wall current), or if the linux luddites favorable review of the
tizen phone they got from india in episode 42 was meaningful. I'm not
trying to predict the future here, there's too much churn and too many
variables and so much of it is happening in other countries with other
languages.

But programming around a bureaucratic ruleset imposed and maintained
by a large corporation strikes me as something with an inherently
finite lifespan.

Unix survived because it was simple. It was significantly simpler than
the systems that already existed at the time it was introduced, it was
simpler than systems introduced since which it has outlived, and linux
is a reboot of minix is a reboot of the original unix, each of which
at least started simpler than the previous thing it threw out and
rewrote.

I tend to focus on the simplest subset that can be made to work and
treat additions to that as optional elements that have to justify
their complexity. As always, "maybe it's different this time"...

Sorry, it's really hard to do serious analysis of this because I can't
come to any actual _conclusions_, just... it's complicated and I get a
headache if I try to work through it too long. It's all circular mush
like the above.

Anyway, I'm not standing in the way of LSM support for toybox. I'm
grumpy about it, but I'm doing it. It's a necessary bad idea.

Rob

 1432788563.0