Talking Smack for Tizen security

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?

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.

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