Civilizing SELinux [LWN.net]

Civilizing SELinux

Posted Nov 18, 2004 17:52 UTC (Thu) by iabervon (subscriber, #722)
Parent article: Civilizing SELinux

I think that a good basic principle for a desktop system would be relatively simple: everything the user isn't expected to know about is restricted by the distribution's policies; anything the user installs, unless it's "official", is prohibited from mucking with the root-owned portion of the system, but can do anything the user can do; a "fakeroot-rpm" system would be very helpful (so you could install a random rpm, and it would look to you like it was installed, but not be able to affect the function of the system other than for you).

The thing that I'd like to see out of SELinux is the ability to tightly restrict the abilities of plug-ins. Your mail program, when you click on an attachment, would run a viewer for it, but would prohibit the viewer from doing anything other than reading files without side-effects, displaying content in its window, and accepting input in its window. This could allow the system to support the distinction in the user's mind between "looking at" something and "running" it. Each new user would probably try saving from a program out of their email and be unhappy, but the concept that you need to export any program you intend to "use" and shouldn't export anything you want to "look at" would fit user's naive expectations far better than current systems (the confusion would come from user's experiences that computers generally violate these expectations).

(Log in to post comments)

Civilizing SELinux

Posted Nov 26, 2004 4:38 UTC (Fri) by spender (subscriber, #23067) [Link]

When can we expect to see Fedora fix their information leaking glibc that makes arbitrary code execution trivial for suid apps?
When can we expect to see the Fedora project implement their own quality assurance that would prevent the frequent crop of problems involving marking PT_GNU_STACK on libraries where it is unnecessary, silently removing any NX protection for all processes that load the libraries?
When can we expect RedHat developers, when presented with bugs of the above type in their poorly engineered distribution by users of PaX/grsecurity, to fix the mentioned bugs, instead of completely dismissing them without even understanding them?

How about a little less SELinux hype, and a little more time spent on understanding security? It's clear RedHat is more interested in buzzwords and making a mockery of people involved in real security research. The longer you continue your propoganda machine, telling your users that "crypto-signed modules stop rootkits" and "SELinux turns a potential system compromise into WORST CASE modified DNS replies," the more you are lulling them into a false sense of security.

Let's not tell the users about kernel exploits (which are more prevalent now than bugs in suid apps) or how easy it is to execute arbitrary code on a default fedora install, because our image as great pioneers in the field of security (which has amounted to cheap ripoffs of code present 3 years prior to RedHat ever entering the game) is much more important than the security of our users.

I've also wondered why RedHat is so unnecessarily anal on the side of access control to be using SELinux, but so overwhelming lax on the side of stopping exploits in the first place to be using Exec-Shield. This conflict is confusing to me, as it seems the latter is more important.

Immunity has exploits that work *reliably* against Fedora with Exec-Shield. Of course, as Immunity doesn't release exploits, your precious image won't be tainted, which is what you really care about, right? Want to bet that if someone were to send a mail to FD and Bugtraq demanding that Fedora fix their information leaking glibc that they've refused to fix for months now, it would be fixed? Why do you think that is? It's easy to blow off your security problems as long as they hide in your bug tracking system, outside of the view of the general public.

Civilizing SELinux

Posted Nov 26, 2004 4:58 UTC (Fri) by bluefoxicy (guest, #25366) [Link]

Want to bet that if someone were to send a mail to FD and Bugtraq demanding that Fedora fix their information leaking glibc that they've refused to fix for months now, it would be fixed?

Brad, do us all a favor. You're pretty smart, you can map out these things and make a comprehensive report on what's wrong, why it's wrong, and why it needs to be fixed, right? Go do it.

I'd really love Linux and hell my favorite distribution to carry the "security torch," and really want to see PaX and GR get the credit they deserve. SELinux and RSBAC are good too though; but I personally despise the hype SE gets, not because anything else is better or worse, but because a lot of people get just that-- hype.

When you focus on ONE solution, you come up with a crowd that thinks it's a magic bullet that will mitigate everything else, sometimes even including patches. We went through the same kind of thing with firewalls. Norton Personal Firewall, Zone Alarm, Black Ice, all things people thought "would stop [crackers]" all by themselves. I wasn't around to see if they did the same thing with Antivirus software, though I imagine this "magic program that removes [cracker] programs will fix everything!!!" Most people still blame 100% of their problems on viruses.

You need a diverse range of solutions: PaX, MAC, GRSec's kernel enhancements, SSP, firewalling, augment ClamAV with heuristics, use application proxy firewalls and firefox/thunderbird plug-ins to scan for malware in web pages and e-mail, etc.

I'm not sure what my exact point is WRT this topic, but there's stuff relavent here I'm sure, since I kind of went all over the place.

Civilizing SELinux

Posted Nov 26, 2004 5:22 UTC (Fri) by spender (subscriber, #23067) [Link]

Here's the situation: We've filed the bug reports. We've shown that it leaks the base addresses for mmap randomization. It's plain as day to see: run the suid app with LD_DEBUG=all multiple times, and you'll see the library addresses, which will be different each time. Jakub Jelinek's reply has been that it "doesn't leak specific symbol addresses." I'm not sure he understands that if you have information about the mmap base, you can easily calculate a specific symbol address from it. We've shown him another environment variable that does leak specific addresses, and his only reply has been "maybe we should fix this." I've not seen a fix announced yet. That was months ago: they've released updated glibc packages since then not containing any of these fixes.

What do you do when the person in control of the code is too stupid and stubborn to fix his own bugs? Is it my job to hold the hand of this jerk who is too concerned with being a smart-ass to fix his own bugs?

Civilizing SELinux

Posted Nov 26, 2004 5:52 UTC (Fri) by bluefoxicy (guest, #25366) [Link]

If I can LD_DEBUG=all and run a program, I can find the libraries it uses and find the symbols at offsets, and calculate that. You are indeed correct about this.

I also read that LAZY binding allows you to block STDOUT at critical points and exploit race conditions on infinite windows instead of milisecond-wide windows.

I for one am glad that Gentoo has a dedicated security team that either creates or abducts any patches that fix ANY security concern, rather than wander around and go "huh that might not really be a problem maybe we shouldn't change it . . . ."

bluefox@icebox ~/data/programming/woct $ LD_DEBUG=all su
Password:

You said something about posting to BugTraq about some of these vulns. Has nobody done this? It may not be the best way to get in bed with them, but if there's a security issue that *needs* *to* *be* *fixed*, it may just be time to hit them in the face with the frying pan of reality. Then again, I don't know; I'm too busy playing FF8 to think about this right now.