On Thu, May 28, 2015 at 11:55 AM, enh <[email protected]> wrote: > > > On Tue, May 19, 2015 at 9:31 PM, Rob Landley <[email protected]> wrote: >> >> Looking at the smack-10 tree ala: >> >> commit cbc95a1a00ae0a1a806e7cc241cdf7b821ee4951 >> Author: José Bollo <[email protected]> >> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
