Talking Smack for Tizen security [LWN.net]

Talking Smack for Tizen security

Posted Jun 6, 2013 19:48 UTC (Thu) by Method (guest, #26150)
In reply to: Talking Smack for Tizen security by ware
Parent article: Talking Smack for Tizen security

Care to explain this? Middleware MAC is only enforcing the access controls already present in Android. Newer, experimental MAC implementations in the middleware are just that, experimental, not something in a released version of a device.

The SELinux policy in SE Android is doing what the Tizen policy is doing, enforcing access to kernel objects. Why is it that the SMACK policy is an order of magnitude large *and* doesn't protect system resources (e.g., all system apps are running as _ and all app labels have rwxa to _). Further, a *fundamental* concept of SMACK is that root processes (technically processes with MAC_* related capabilities) have full access to modify SMACK, since /smack/onlycap isn't set that means all those system processes running as root have that access.

Contrast to SE Android where very few services run as root, and they are all constrained by policy to only be able to do what they need.

So, in conclusion, not only is your policy 25 times larger but it doesn't protect anything.

to post comments

Talking Smack for Tizen security

Posted Jun 6, 2013 21:13 UTC (Thu) by ware (guest, #83607) [Link] (4 responses)

I don't believe anyone in the presentation or this article discussed SE Android so I don't know why you're bringing up an experimental MAC implementation usable only for a specific Linux solution into a discussion about a general purpose Linux platform focused on many different product verticals.

Talking Smack for Tizen security

Posted Jun 6, 2013 21:44 UTC (Thu) by Method (guest, #26150) [Link] (3 responses)

Err. The article is about Tizen, a mobile platform, not a general purpose computing platform. How is it inappropriate to compare it to SE Android, a mobile platform?

Talking Smack for Tizen security

Posted Jun 6, 2013 21:57 UTC (Thu) by Method (guest, #26150) [Link]

And you never explained:

"Very true. However, much of the previous complexity now exists in the userspace components."

The main difference with SELinux on Android is that Zygote has to set a label for new apps that it runs, because it does not fork/execve() as an optimization. Interestingly enough SMACK has _always required a helper app to set a new label on a new processes_, moving much of the complexity into userspace components.

Oops.

Still not seeing why this is better than the alternative. Can you please explain?

Talking Smack for Tizen security

Posted Jun 6, 2013 22:03 UTC (Thu) by ware (guest, #83607) [Link] (1 responses)

Tizen has a mobile profile yes but it is not a mobile platform in the sense Android is. Additionally SE Android is targeted at...Android. Surprise! Tizen couldn't use it.

Talking Smack for Tizen security

Posted Jun 6, 2013 22:27 UTC (Thu) by Method (guest, #26150) [Link]

You still haven't explained the comment above.

Tizen *could* use SELinux, and would likely be able to have a comparable policy to SELinux on Android.

Talking Smack for Tizen security

Posted Jun 6, 2013 21:26 UTC (Thu) by spender (guest, #23067) [Link] (7 responses)

I'll let you guys fight out whose multi-thousand-rule policy is more useless than the other.

Meanwhile, back in reality, you're wasting all this time and effort barricading the windows while attackers continue to break right through the front door. Using the same exact techniques since 2007 to invisibly disable SELinux, AppArmor, Smack, IMA, and all other LSMs, no less:

http://www.youtube.com/watch?v=KvREwhfQmbc
http://www.youtube.com/watch?v=WI0FXZUsLuI

But please go on with your high and mighty speech, I'll wait here for the response of "reality and the most critical and easiest exploits aren't in our threat model".

-Brad

Talking Smack for Tizen security

Posted Jun 6, 2013 21:39 UTC (Thu) by ware (guest, #83607) [Link]

If you're concerned with high and mighty speeches, you shouldn't give them.

Talking Smack for Tizen security

Posted Jun 7, 2013 9:54 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (5 responses)

Is there some reason you didn't simply say "How does your system cope with the attacks shown at (link) and (link)?"

Talking Smack for Tizen security

Posted Jun 7, 2013 11:59 UTC (Fri) by spender (guest, #23067) [Link] (4 responses)

Yes, because Method here already knows the answer to that question. He was in the audience in 2010 when I gave the following talk at the Linux Security Summit: http://grsecurity.net/spender_summit.pdf In other words, he's not ignorant, just an unabashed SELinux shill with much to profit off its illusion of security. Formerly of Tresys (developers of the reference policy used in RHEL and Fedora, whose business centered around SELinux) and now with his own SELinux-based company.

So I don't really expect a response, I've already predicted the response based on previous discussions when reality is brought up. SELinux is a convoluted solution that looks great on paper to people in their 50s still clinging on to their copy of the orange book, but it was not created to stop malicious attacks and was developed by people who have no clue about hacking or how to hack. Yet this doesn't stop them from promoting it for whatever purpose (http://danwalsh.livejournal.com/10131.html, ROP anyone?) and making pointless claims of superiority because their access control system has more useless features and complexity than the others. It reminded me of the too-ironic post from Stephen Smalley while trashing AppArmor: http://lwn.net/Articles/399053/. A reasonable person could say the same exact things about SELinux. Its proliferation continues as long as everyone maintains the false assertion of superiority its proponents love throwing around.

My capabilities post was republished in many places: http://forums.grsecurity.net/viewtopic.php?f=7&t=2522
but it appears no one gave any thought to the last two paragraphs, which I'll reproduce here:

> So, what does this all have to do with PaX, interpreters, and arbitrary code execution on the filesystem? Withstanding a bug in the privileged code that would, for instance, allow the mknod()ing of arbitrary devices, none of the things listed above are operations performed normally by privileged applications. In order to perform these (sometimes complex) actions, the flow of execution needs to be diverted and controlled. Access control systems strive to remove privilege/capabilities from all programs except those that require it. Traditionally, they had only been interested in certain interactions with the system, but not with the *cause* of those interactions. Thus, for an app that needed to exec /bin/sh for some controlled operation, the access control system would see no problem with also allowing it to exec a root shell. The addition of PaX and the concept of removing arbitrary code execution from processes (and in the future, extending this process further with other techniques) has changed all this in a significant way that, to my knowledge, hasn't been properly articulated elsewhere.

> Under a traditional access control system, compromising an application immediately leads to being able to easily and artfully weave the privileges of that process into something usable. We rarely get nice, simple bugs with no constraints. Those constraints can make the bug unexploitable or can introduce limitations/requirements on the exploitation end. These are the constraints just imposed by the bug/application itself, not even considering the constraints imposed by the protections of the system. It's easy to think about chaining a kernel exploit when the address space of a process is your virtual playground, but what would you do without arbitrary code execution in combination with strict access control, randomized address space layout, and some form of fptr protection/control flow integrity? What if many of these protections were also present in the kernel you're trying to attack? How often will such an attack be possible under bug/application constraints? I'm not sure many have thought/had to think about this.

I believe the complexity of SELinux and other similar access control is built off being stuck in an academic 1980s mindset, unable to consider or adapt to the realities and improvements of the past decade, which really have changed how we need to think about attack and defense.

To respond directly to your nonconstructive post, I feel that honesty and speaking truth to power are more important than social niceties. I also don't believe all opinions are created equal. Some of them are formed by people who have been living in a funded SELinux reality distortion field for the past 11 years, while others have been involved in actual security.

-Brad

Talking Smack for Tizen security

Posted Jun 7, 2013 14:10 UTC (Fri) by Method (guest, #26150) [Link] (3 responses)

Reminds me of something I wrote in 2004:
http://www.gentoo.org/proj/en/hardened/primer.xml

Talking Smack for Tizen security

Posted Jun 7, 2013 14:36 UTC (Fri) by spender (guest, #23067) [Link] (2 responses)

I'm glad your 2004 self at least learned something from me (unless the important point re: access control was contributed by Adam Mondl, I'll ask him when he wakes up). Perhaps your 2013 self needs reminding of that point, since you are only pushing the last line of defense and not the other more important aspects ;)

-Brad

Talking Smack for Tizen security

Posted Jun 7, 2013 14:46 UTC (Fri) by Method (guest, #26150) [Link] (1 responses)

Oh, Brad.

I'm glad you think you invented layered security, and still have a victim complex.

Use the way back machine, you'll see that all of that was mine.

You have no idea what I push and what I don't. Like always you are content to sit on the sidelines and say "I told you so" over and over as if anyone cares. Your 2013 self is a spitting image of your 2004 self, sit around and blame and whine and troll.

Nothing to see here folks, move along.

Talking Smack for Tizen security

Posted Jun 9, 2013 22:14 UTC (Sun) by spender (guest, #23067) [Link]

I know you wish there was nothing here to see, but since you've brought up some things that demand a response:

If I didn't pioneer actual layered security in the way in which it will be done in the future on host systems, then who did? I mean, there is a reason why you're talking about grsecurity in that 2004 article and not something else, isn't there? ;)

Anyone can read your blog and see what you're pushing in public (just look at the top 3 tags here: http://securityblog.org/tags.html). It's quite clear it's SELinux. Now if you're saying you're also pushing (via advocacy I guess, since you've done no research/work in this field) kernel self-protection as a necessary prerequisite for any form of mandatory access control, then I'm glad to hear you're advocating the use of grsecurity in private, as we've been the only name in the game since 2003.

I'm quite content being someone actually producing useful code to solve real problems, speaking up against the status quo, liars, charlatans, and shills. I trust history will look back on that more favorably than someone pushing the over-complicated SELinux for the past 10 years because his previous employer put itself forth as the only people knowledgeable enough to develop SELinux policies (I recall very well this being said at LSS 2010). Curious coming from someone who claims to understand the proper role of access control in overall security, seething with pride here in this thread that his SELinux has more useless knobs than Smack.

-Brad