Rate this page del.icio.us  Digg slashdot StumbleUpon

What’s new in SELinux for Red Hat Enterprise Linux 5?

by Dan Walsh

Dan Walsh will be presenting an overview of “What’s new with SELinux in Red Hat Enterprise Linux 5″ at the Red Hat Summit on Wednesday May 9th at 3:00 PM in the “What’s New” Track. This article presents some of the material from that talk, and was written with frequent magazine contributor Len DiMaggio.

This article has been corrected since its original publication.

Software security? Do I have to?

For many people, security is a subject that they only think about after something bad happens. Like buying a home alarm system after your home has been burgled. Why? One reason is denial–after all, bad things always happen to someone else. Additional reasons may be the perception that security, especially in software, is too hard. People either don’t use it, or use it incorrectly1. Computer security may prevent you from performing tasks that you want to accomplish. Or the security is not all that effective.

In Red Hat Enterprise Linux 5, enhancements to SELinux address these problems by making the coverage more comprehensive, the tools easier to use and manage, and–at the same time–continuing to not require changes to application software.

This article examines these enhancements in greater detail. We will discuss other SELinux-related subjects in subsequent articles.

Lets take a look at SELinux, how it works, and what makes it effective. And why it should matter to you.

SELinux background

I like to begin technology discussions with a version of the question that Al Franken used to ask on Saturday Night Live. “What does this mean for Al Franken?”

So, here’s our question: What does SELinux mean for you?

The answer is that you, your personal information,, business information–including financial information–and intellectual property are at risk. If you think that you’re immune to this risk, you’re in denial. All you have to do to see examples of this risk is watch or read the news. In the past few months, literally hundreds of thousands of people world-wide have been directly affected by identity theft.

How does SELinux protect against these threats? How is SELinux different from firewalls, passwords, and other security software?

Security like file permissions or user account passwords are Discretionary Access Control (DAC) systems. They are referred to as “discretionary” because every object (files and directories) has an owner, access to objects is based on user identify, and users (the object owner or root) are able to–at their discretion–grant access to other users. In contrast, SELinux is a Mandatory Access Control (MAC) system. Access to objects is controlled by a system-wide policy, regardless of the ownership of any object, enforced by the kernel. Users, including the root user, cannot grant other users access to their objects in violation of the policy. Using a MAC security system requires a different mindset. When people first encounter a permission violation enforced by SELinux, they often try to diagnose the problem by checking the ownership of the file and the read/write/execute permissions on the object. But even if the ownership and permissions are correct, the access is still blocked. The user and file/dir ownership is not the deciding factor with SELinux, the policy is.

Why is this distinction important? Here’s an example. Let’s say that you’re running an http server for a retail web site paired with a mysql database containing customer data (including credit card information). The software that runs the web site has a security vulnerability. If someone breaks into the server, what’s the risk to your system? it’s just the web sever, right? Wrong! Suppose the attacker is able to obtain a root shell. With root on a non-SELinux system, he can access your credit card database. Once the attacker gains access through the web server, the whole system is at risk. If this same system was protected by SELinux, the user might be able to use the vulnerability to break into the web server, but he would be prevented from touching the database or any other parts of the system, even if he got a root shell. SELinux would only allow the http process to communicate with the database through the named pipe. In other words, with SELinux, you don’t trust the application2–which may be buggy, insecure, or compromised–to secure itself. You rely on the SELinux policy.

This diagram illustrates the httpd web server example:

Fig.1  httpd server example

Fig 1. httpd web server example

SELinux provides security to a system in a way similar to a ship or submarine’s design. They are divided into multiple water-tight compartments. If the ship springs a leak in any one compartment, only that compartment will fill up with water.3

The following diagrams illustrate this difference:

Fig.2 Discretionary and mandatory access control diagrams

Fig 2. Discretionary and mandatory access control diagrams

A vibrant community

Before we discuss enhancements made to SELinux in Red Hat Enterprise Linux 5, I want to make one very important point about what sets SELinux apart from other security software. SELinux could not have been developed and would not be as reliable, comprehensive, and effective if it was not supported by a vibrant open source community.

SELinux, as implemented in Red Hat Enterprise Linux 5, is a direct result of the work on earlier versions in Fedora(TM) Core (FC) 2, 3, 4, 5, and 6, as well as Red Hat Enterprise Linux 4. It’s unlikely that a system as comprehensive, integrated, and robust as SELinux could have been created without the work of the community. The scale and complexity of the task is too large for any closed organization or corporation. The community gives SELinux access to millions of potential users, testers, and contributors. The testing/QE effort alone is huge4.

But wait–couldn’t a large, well-financed corporation achieve the same results through a public beta test? Not likely. Think of your own experiences with beta software. You download it, then simply stop using it when something goes wrong. Within the Fedora Core community, however, SELinux users are more actively involved, often personally invested in the software5. The community doesn’t only report bugs, but also contributes patches (for example, SELinux policy changes). When I refer to the SELinux community as being “vibrant,” I chose my words carefully. In this regard, it is a classic example of an open source project that has migrated in stages from the community tthrough Fedora Core and into Red Hat Enterprise Linux. This diagram illustrates these stages.

Fig.3 Development model

Fig 3. Development model

SELinux = Red Hat Enterprise Linux

SELinux is not a set of packages, add-ons, or optional extensions layered onto an older version of an OS. When you use SELInux on Red Hat Enterprise Linux 5, you’re running Red Hat Enterprise Linux 5. All of it. In comparison, versions of Trusted Solaris trail the mainstream version of Solaris by months–if not years6. With SELinux, you don’t give up any of the current features or enhancements in Red Hat Enterprise Linux 5. And your applications don’t have to change, either.

We started this article by asking what SELinux means to you. Now, let’s talk about what the most recent enhancements to SELinux mean to you. What’s new in SELinux in Red Hat Enterprise Linux 5? Let’s take a look.

Doing more with comprehensive system space coverage

In the context of describing the how SELinux protects a system, there are two categories of system usage: system space and user space. System space refers to all programs started during the bootup process. Some examples are crond, named, and services such as httpd and mysqld. User space refers to programs started by a logged-in user.

In Red Hat Enterprise Linux 4, 15 services 7 in system space had confined SELinux domains defined. In Red Hat Enterprise Linux 5, over 200 processes are confined by SELinux. The improved SELinux policy is much more precise in how it governs the operation of these services. It’s far less likely that a Red Hat Enterprise Linux 5 system space process will be compromised or encounter an error caused by an SELinux policy not handling the specific requirements (e.g., file or directory access) of a service.

User space applications will be locked down in future Red Hat Enterprise Linux releases. In Red Hat Enterprise Linux 5, logged-in users still run mostly unconfined by the SELinux policy, although the building blocks are in place for confining certain users. There are a couple of things to remember about user space in Red Hat Enterprise Linux 5. First, in the context of SELinux, a “logged-in user” refers to those that have accessed the system via the login, sshd, or xdm programs. This is different from an exploit (such as a break-in via httpd) where a user shell is opened. This type of attack would be confined by SELinux’s handling of the httpd process. Second, even in the unconfined user space, SELinux protects against buffer overflow attacks by performing executable memory checks. Buffer overflow attacks are a classic system exploit technique. An overflow writes more memory than a buffer is configured to hold, and includes executable code in the data being written. In Red Hat Enterprise Linux 5, SELinux checks memory to ensure that what should be writable is not changed to be executable.

Easier management

One of the problems with any Mandatory Access System like SELinux is that confined applications get permission denied, and administrators have no idea why. Over the years, UNIX/Linux administrators have learned that permission denied means that an application either does not have ownership of a file/dir, or it does not have the correct read/write/execute privilege. With SELinux, they look in /var/log/messages (or if auditing is turned on the messages end up in /var/log/audit/audit.log) and see this:

logtype=AVC msg=audit(1176392795.244:2036): avc:  denied  { getattr } for  pid=6705 comm="httpd" name="index.html" dev=dm-0 ino=3180003 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file

The universal first reaction of most admins is to say: “What the h**l is that?” What makes log messages like this so difficult to read is that they are not intended to be human readable. (Pardon the pun.) The format of these log messages is a set of name=value pairs that can be parsed programmatically.

In Red Hat Enterprise Linux 5, we have added a new program called setroubleshoot. This daemon watches the audit logs for SELinux-generated errors and translates them into human readable form.

SELinux access denial error messages like the example above are no longer written to /var/log/messages, they will show up in /var/log/audit/audit.log and setroubleshoot will translate these messages and write them to /var/log/messages. For example, in Red Hat Enterprise Linux 4, a message like this would have been written to /var/log/messages or /var/log/audit/audit.log:

time->Thu Aug 24 15:50:58 2006
type=AVC_PATH msg=audit(1156449058.917:552):
path="/var/www/html/index.html"
type=SYSCALL msg=audit(1156449058.917:552): arch=40000003 syscall=196
success=no exi
t=-13 a0=8d4d4d0 a1=bfb5e97c a2=434ff4 a3=2008171 items=0 ppid=23799
pid=23805 auid=3267 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
tty=(none) comm="httpd" exe="/usr/sbin/httpd" subj=user_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1156449058.917:552): avc: denied { getattr } for pid=23805 com
m="httpd" name="index.html" dev=dm-0 ino=6260297
scontext=user_u:system_r:httpd_t:s0
 tcontext=system_u:object_r:user_home_t:s0 tclass=file

In Red Hat Enterprise Linux 5, this message is written to /var/log/messages:

Aug 24 15:53:10 localhost /usr/sbin/setroubleshootd:      SELinux is
preventing /usr/sbin/httpd "getattr" access to /var/www/html/index.html.
See audit.log for complete SELinux messages.

At the same time, the following screen icon is displayed for the user.

Fig.4 Screen icon

Fig 4. Screen icon for setroubleshoot

When the user clicks on that icon, the setroubleshoot (“SELinux Troubleshooter) utility is opened. Setroubleshoot analyzes the error messages, provides a detailed description, and offers a remedy. Here’s an example of what setroubleshoot displays for users:

Fig.5 Browser display

Fig 5. setroubleshoot browser display

Easy configuration and customization

In order to modify the current SELinux policy on a system running Red Hat Enterprise Linux 4, a system administrator would have to download the policy source, edit the policy source code, and rebuild and install the policy using tools like “make install.” The introduction of policy modules made this process easier and less error-prone. A system administrator could use the audit2allow utility to generate policy module updates directly from audit.log error messages. These modules function in a way similar to kernel modules in that they enable system administrators to modify part of the policy (a specific module) without having to rebuild the entire thing. So if you had an AVC message that was preventing an application from running httpd, you could simply execute the following to update the policy.

grep httpd_t /var/log/audit/audit.log | audit2allow -M myhttpd; semodule -i myhttpd.pp

Certain confined domains can be run in multiple different ways. Policy writers have the ability to write if/then/else code in policy, and let the administrator set up the policy they prefer. These if/then/else switches are called booleans. Configuring and customizing a policy is made easier by the system-config-selinux utility. This GUI utility lets system administrators modify the policy by selecting changes from a set of pre-defined booleans. With the system-config-selinux utility, the administrator can concentrate on understanding the specific security needs of his/her system. Changing the policy is as simple as selecting check boxes. Also, if the system is set up to run an application one way and the policy is set up differently, setroubleshoot will suggest the boolean needed for the code to work properly.

Fig.6 Choices

Fig 6. Suggestions

System administrators sometimes need to change the layout of their systems. For example, they may want to put the http pages in /opt/www rather than /var/www/html. In Red Hat Enterprise Linux 4 they could do this by editing the configuration file /etc/selinux/targeted/contexts/files/file_context.local. In Red Hat Enterprise Linux 5, there is a new command semanage fcontext -a which allows you to make these changes permanently. system-config-selinux also has a screen for this. And sometimes administrators want to change the ports that a confined domain listens on. In Red Hat Enterprise Linux 4 they would have had to modify policy. In Red Hat Enterprise Linux 5, semanage and system-config-selinux have the ability to change the ports.

Conclusion

Threats to your computer system and your data are real. And they are not static. They are always evolving to be more effective and dangerous. In order to keep your data, your system, and your home directory safe, SELinux is not static either. It is constantly evolving to be more effective and easy-to-use, from the introduction of GUI-based utilities to improved error reporting. The implementation of SELinux in Red Hat Enterprise Linux 5 is the result of experience gained over several Fedora Core releases and the hard work of contributors from a vibrant open source community. And it’s certainly not the end of the evolution of SELinux. It’s just a step along the way.

So turn SELinux on and keep it running. Don’t end up like Sidney in this–mostly based on fact–conversation (names have been changed to protect the, uh, innocent8):

Sidney:  This application stinks. It keeps crashing.
Walter:   Did you look /var/log/messages?
Signey:  (Embarrassed) No – OK I will
Walter:   (Smiles knowingly)
Sidney:  What's with all these SELinux log messages?
Walter:	  Oh, the application is attempting an action prevented by the policy.
Sidney:	 SELinux? OK, I'll just turn it off.
Walter:	  While you're at it, why not stuff $100 bills in all your pockets and go for a walk in the park at midnight?
Sidney:	 I would never do that – it wouldn't be safe!
Walter:		(Smiles knowingly)

References

Acknowledgments

The authors also want to give credit to the anonymous Red Hat marketing team members who created some of the graphics in this article

About the authors

Dan Walsh has over 20 years experience in the computer field. He has spent most of his career working on Security Applications and platforms. He spent several years working on the Athena Project while at Digital Equipment Corp. Dan was also involved in designing and developing the AltaVista Firewall and AltaVista Tunnel (VPN) Products. He has worked for Netect developing HackerShield, a Vulnerability Assessment Product. Netect was acquired by BindView, where he continued working on HackerShield and developed a new product, BVControl for UNIX. At Red Hat, Dan has led the SELinux project, concentrating mainly on the application space and policy development. Dan Graduated with a BA in Mathematics from the College of the Holy Cross and a MS in Computer Science from Worcester Polytechnic Institute.

Len DiMaggio is a QE Engineer at Red Hat in Westford, MA (USA) and has published articles on software engineering in Red Hat Magazine, Dr. Dobbs Journal, Software Development Magazine, IBM Developerworks, STQE, and other journals. Len always has SELinux running on his Linux systems.


1 For example, you may have a firewall running on your system, but if it allows all incoming and outgoing traffic, it’s not providing any real security.


2 What about applications that are well-written, such as Firefox? Well, Firefox accepts plugins. You may have confidence in Firefox itself, but can you be equally confident about EVERY plugin? Probably not!


3 Yes, yes, yes. I did see the film “Titanic.” That ship had a serious design flaw where the tops of the watertight compartments were not closed and water could overflow from one to another. This is not a problem with SELinux.


4 Eric Raymond, “Given enough eyes, more bugs are shallow.”


5 It’s like that line by Larry Summers about how no one in history has ever “washed a rented car.” We don’t rent SELinux, we live with every day.


6 Wikipedia: Solaris, opensolaris.org


7 Red Hat Magazine, March 09: Understanding your Red Hat Enterprise Linux Daemons


8 The names used in this paper actually belong to a friend’s cats.

28 responses to “What’s new in SELinux for Red Hat Enterprise Linux 5?”

  1. spender says:

    Those pictures showing how it’s impossible to completely compromise a system or kernel when MAC is enforced are really interesting. Did you guys not see my kernel exploit which completely disables SELinux and completely compromises the system?

    To rephrase, I know you’ve seen the exploit (Steve Grubb was suspiciously silent on the list after posting of the exploit, and I know he’s talked to other individuals in the security community about it), you’re just knowingly giving your users a false sense of security.

    For those that have finished reading the above propaganda, here’s the mentioned exploit and discussion:

    http://lists.immunitysec.com/pipermail/dailydave/2007-March/004133.html

    I’ll be surprised if this comment is approved.

  2. k0k says:

    Amazing, excelent article.

  3. David Cafaro says:

    Spender:

    Thank you interesting read, but I think your being adversarial (understandable given you work on a competing technology). Yes you can’t protect against all Kernel Attacks, the kernel is ring 0, it’s is going to be a weakness for ALL security mechanisms (including PaX) in Linux (and any OS). SElinux and PaX both help to lower the exposure, but it won’t eliminate it. I mean even PaX has had it’s exploits (to greater and lesser degrees, just a quick google):

    http://secunia.com/advisories/14489/

    http://www.digitalarmaments.com/2007200184936274.html

    There will be more and SELinux, Pax, and AppArmour will all have their day in the “You’ve been powned” limelight. But I for one am still glad SELinux is improving and there to help.

  4. David Cafaro says:

    Oh, and excellent article here as well. Good run through of SELinux in RHEL 5.

  5. spender says:

    “An overflow writes more memory than a buffer is configured to hold, and includes executable code in the data being written.”

    This type of attack is already covered by ExecShield, SELinux adds nothing here. What SELinux adds is a policy-specified protection against an attacker who already is able to perform ret-to-libc or ret-to-PLT attacks against a protected application in an effort to prevent arbitrary code execution by preventing the existence of writable and executable memory areas — something PaX (http://pax.grsecurity.net) has been doing for over 6 years now.

    (Also note that with a kernel exploit, the attacker can execute their arbitrary code in userland, regardless of SELinux’s protection — my exploit does this. This is not possible under PaX)

    “In Red Hat Enterprise Linux 5, SELinux checks memory to ensure that what should be readable is not changed to be executable.”

    You mean “writable”, not “readable”.

    Dan Walsh apparently commits changes to SELinux, but it seems he doesn’t have a real grasp of the technologies included in it.

  6. Bascha Harris says:

    Thanks for the correction. :) The change has been made.

  7. Len DiMaggio says:

    wrt: You mean “writable”, not “readable”.

    That was a typo – on my part – fixed now – thanks…

  8. PaX Team says:

    David said:

    > Yes you can’t protect against all Kernel Attacks, the kernel is
    > ring 0, it’s is going to be a weakness for ALL security mechanisms
    > (including PaX) in Linux (and any OS).

    you’re wrong, it’s not true at all, hasn’t been for the past 4 years at least if we’re talking about PaX. i suggest you check out the KERNEXEC and UDEREF features in PaX, they make entire *classes* of otherwise exploitable *kernel* bugs non-exploitable. case in point, the bug spender’s SELinux exploit abused *cannot* be exploited under UDEREF therefore a grsecurity system was safe whereas SELinux systems weren’t.

    > SElinux and PaX both help to lower the exposure, but it won’t
    > eliminate it.

    what do these two have to do with each other? apples to oranges?

    > I mean even PaX has had it’s exploits

    you seem to be very confused. PaX has never had *any* exploits whatsoever, given that it’s a security patch, not an exploit. what you probably wanted to say but didn’t know the proper terminology for is that PaX had exploitable bugs in it (and probably still has, much like any software of similar complexity). bugs and exploits are very different animals, the latter is written to, well, exploit the former – they’re two *different* pieces of software. if you don’t believe me, just visit your favourite exploit collection website and download what you believe is an ‘exploit of PaX’ – what you will get is not PaX, but a standalone piece of software having about 0 lines common with PaX (same goes for any other bug and corresponding exploit of course).

    with that said, you managed to cite the wrong bugs because

    – the first one was discovered by me and published with full
    disclosure, something Red Hat programmers cannot really claim
    (there’s a certain irony in comparing apples to oranges ;-).
    i know of some Exec Shield bugs that were fixed silently, so
    silently in fact that not even other Red Hat programmers were
    aware of them and failed to fix them in the Xen port of Exec
    Shield for over half a year. also, your linked advisory doesn’t
    even point to an actual exploit for this bug (showing how confused
    you are about this whole bug vs. exploit issue).

    – the second bug is *not* exploitable under grsecurity with the
    proper security policy in place. not to mention that there has
    *never* been an exploit for this bug (beyond DoS, that is) even
    for an otherwise vulnerable setup.

    now how many exploitable bugs did SELinux have during its existence? how many turned out to be non-exploitable due to factors such as proper policy? if you weren’t just trolling with your comment, i’d like to see some real answers to these questions.

  9. David Cafaro says:

    Oh, boy, first off, wouldn’t be trolling if I put my real name and website down. Trolls generally hide behind anonymity and start flame wars. That’s not what I was trying to do. I was trying to put down a fair and calm statement that NO MATTER what security you have, if someone can exploit the kernel they have potential to get around anyones security mechanism.

    > you’re wrong, it’s not true at all, hasn’t been for
    > the past 4 years at least if we’re talking about
    > PaX. i suggest you check out the KERNEXEC and UDEREF
    > features in PaX, they make entire *classes* of
    > otherwise exploitable *kernel* bugs non-exploitable.

    Not sure where you proved me wrong there. I said you “can’t protect against all kernel attacks” and you said yours protected against entire *classes* of attacks. *classes* != ALL

    Yours protects against some that SELinux alone cannot, but that isn’t the same as proving me wrong. I stick with my statement.

    > you seem to be very confused. PaX has never had *any*
    > exploits whatsoever, given that it’s a security patch,
    > not an exploit. what you probably wanted to say but
    > didn’t know the proper terminology for is that PaX had
    > exploitable bugs in it (and probably still has, much
    > like any software of similar complexity). bugs and
    > exploits are very different animals, the latter is
    > written to, well, exploit the former – they’re two
    > *different* pieces of software. if you don’t believe me,
    > just visit your favourite exploit collection website
    > and download what you believe is an ‘exploit of PaX’
    > – what you will get is not PaX, but a standalone piece
    > of software having about 0 lines common with PaX (same
    > goes for any other bug and corresponding exploit of course).

    Oh come on, have you ever heard the phrase “splitting hairs”? You know what I meant, and I would say the vast number of people reading it understood what I meant. No I am not calling PaX an exploit. Should I have said “The PaX patch to the kernel has had bugs that allowed exploits to circumvent the patch protections”?

    As for the rest, given our misunderstanding of each others frame of communication, I think you gave a great explanation of exactly what I meant but in your words. PaX had bugs that allowed exploits to bypass the security provided by the PaX patch to the kernel. I commend you for the full disclosure of your issues, that’s a GREAT thing. As for the SELinux and Redhat people, it’s too bad things have been fixed and not reported, hopefully that will not be the case in the future. Given the size of the projects, company and the fact it’s not just those two groups working on it, it probably won’t be the last. No, it’s not a good thing, but it’s a much different situation than the closer nit and smaller group dynamics of the grsecurity group. Finally just because their isn’t an active exploit (though a DoS is a form of exploit, denial of server means a wasted resource), doesn’t mean it isn’t an issue.

    Yes pressure needs to be put on to keep improving the system, but I don’t think throwing accusations of incompetence and cover ups solves anything. Most likely it was not a conscience cover up. It was something that needed to be fixed, it was fixed, and a branch missed the fix. I don’t know, wasn’t involved in it, but would rather give the benefit of the doubt.

    How many exploits did SELinux have during it’s existence? No idea, several I’m sure, but they were probably bugs that allowed exploits to bypass it ;). As for getting real answers and hard numbers, not going to do that right now, I’m at home hopefully going to relax soon, and the lack of answers to your questions certainly does not define my posts as being a Troll.

    I’ll give you the benefit of the doubt that you just didn’t understand what I was trying to get across, that I wasn’t saying the PaX/grsecurity was bad, that I’m not saying SELinux is the solution to all, but that they both provide security PaX more toward kernel, SELinux more toward cross application/user. Yes there is some overlap into both areas on both sides. And yes, owning the kernel gives you a chance to get past both :-).

  10. PaX Team says:

    David said:

    > Not sure where you proved me wrong there. I said you “can’t protect
    > against all kernel attacks” and you said yours protected against
    > entire *classes* of attacks. *classes* != ALL

    maybe careful re-reading of your own statement would help then, let’s
    try it again. here’s what you said:

    > Yes you can’t protect against all Kernel Attacks, the kernel is
    > ring 0, it’s is going to be a weakness for ALL security mechanisms
    > (including PaX) in Linux (and any OS).

    that’s a long sentence with several actual statements in it. there’s
    no contention about the first one, although it’s an easy one to make
    as ‘all’ is such a catch-all phrase and can’t be enumerated and
    analyzed/discussed… if you had said ‘all practical attacks’ then
    there’d be quite a few in academia disagreeing with you.

    anyway, the part i contended and you were wrong about is that just
    because something buggy runs in ring-0, doesn’t mean it’s all lost
    case. you believe it is, we showed a specific case where it wasn’t.

    furthermore, it is possible for the kernel to protect itself from
    privilege elevation in general.

    > Yours protects against some that SELinux alone cannot, but that
    > isn’t the same as proving me wrong. I stick with my statement.

    SELinux doesn’t *at*all* protect against kernel bugs. that’s not what
    it was designed for, it’s an access control mechanism for userland.
    it assumes that the kernel is bug-free (and when it’s not, it falls
    apart as spender’s exploit shows).

    > Oh come on, have you ever heard the phrase “splitting hairs”? You
    > know what I meant, and I would say the vast number of people
    > reading it understood what I meant. No I am not calling PaX an
    > exploit.

    indeed, i knew what you meant, but you apparently didn’t know it. in
    fact, you just made that mistake again. who said that you called PaX
    an exploit? noone did as far as i can see. where did that idea come
    from then? what i said was that PaX hadn’t had any exploits, because
    it is not an exploit collection, it’s a security patch. what it did
    have is exploitable bugs.

    you see, in information security (much like in any other profession)
    we have specific terms to mean specific things, sometimes not obvious
    in their meaning unless you know what’s actually behind them.

    confusing a bug with an exploit is no better than confusing
    ciphertext with the encryption key.

    > Should I have said “The PaX patch to the kernel has had bugs that
    > allowed exploits to circumvent the patch protections”?

    no, you should have simply said what i already said myself (and you
    failed to read or understand): PaX has had exploitable bugs. simple
    enough? and if you wanted to stick to actual facts, you would have
    used ‘bug’ only, as only one of them is provably exploitable (for
    privilege elevation). and if you wanted to be even more correct (or
    what was the word you used, ‘fair’?), you wouldn’t even have
    mentioned any of those bugs because PaX is not a protection mechanism
    against local attacks (something that SELinux is meant to be
    however). therefore it doesn’t matter whether exploitable kernel bugs
    are due to PaX or not, they’re, well, exploitable anyway. the fact
    that PaX does what it can and helps against important classes of
    local attacks is a bonus you get on top of the real protection
    provided against remote attacks (neither feature set is finished
    though).

    > Most likely it was not a conscience cover up. It was something that
    > needed to be fixed, it was fixed, and a branch missed the fix. I
    > don’t know, wasn’t involved in it, but would rather give the
    > benefit of the doubt.

    most likely you’re dead wrong about it. these bugs were found and
    reported by *us* to Ingo Molnar directly. oh yeah, they needed to be
    fixed. what they didn’t need though was the coverup.

    > I’ll give you the benefit of the doubt that you just didn’t
    > understand what I was trying to get across, that I wasn’t saying
    > the PaX/grsecurity was bad,

    which is why you lashed out right in the first sentence at spender by
    calling him adversarial? or why you compared PaX to SELinux (nothing
    to do with each other)? or why you tried patronizing the Red Hat bug
    handling process without having zero idea about the details? ah yeah,
    the benefit of doubt. question is, who benefits.

  11. David Cafaro says:

    I’m going to go about responding to this backwards, as I seems more fit:

    > which is why you lashed out right in the first
    > sentence at spender by calling him adversarial?

    Ok, first off my first sentence:

    > Thank you interesting read, but I think your being
    > adversarial (understandable given you work on
    > a competing technology).

    Was not me lashing out, first I complimented him on an interesting read (his reply, not the article), but that I felt the tone of it was too adversarial. That is not lashing out. I had no reason to lash out, nothing to gain. Apparently you took it as lashing and commenced in what has now become very obviously adversarial in your view.

    > or why you compared PaX to SELinux (nothing
    > to do with each other)?

    I didn’t start the comparison between PaX and SELinux. I mentioned them both, but was not comparing them beyond the fact that they have both have had issues in the past, as in nothing is perfect. Spender in post 5 actually started with the direct comparison of PaX and SELinux. I later then mention that both can have some overlap.

    > or why you tried
    > patronizing the Red Hat bug handling process
    > without having zero idea about the details? Ah
    > yeah, the benefit of doubt. question is, who benefits.

    One gives someone the benefit of the doubt until proven wrong through ones research or verified research of others. Why you label that as patronizing is beyond me.

    > most likely you’re dead wrong about it. these
    > bugs were found and reported by *us* to Ingo Molnar
    > directly. oh yeah, they needed to be fixed.
    > what they didn’t need though was the coverup.

    Good, then they screwed up, and thank you for letting me know. There doesn’t need to be a cover up and if as you state they actively let this one quietly disappear, boo on them.

    Next paragraph up:

    > no, you should have simply said what i already
    > said myself (and you failed to read or understand)

    >provided against remote attacks (neither feature set
    > is finished though).

    This whole paragraph is just a rehash of what we have both been saying.

    Next paragraphs up:

    > who said that you called PaX an exploit?

    You did:

    > it’s a security patch, not an exploit.

    Which is what you implied at this line then went into your Bug vs. Exploit vs. confused rant.

    > you see, in information security (much like
    > in any other profession) we have specific terms
    > to mean specific things, sometimes not obvious
    > in their meaning unless you know what’s actually
    > behind them.

    That sir is to patronize, and I do not appreciate it. I would think someone as intelligent as you appeared to be wouldn’t start down that path.

    > SELinux doesn’t *at*all* protect against kernel bugs.

    Here is a kernel bug (and paired 0-Day exploit) that SELinux protects against:

    http://xforce.iss.net/xforce/xfdb/27790

    Next batch of paragraphs:

    > anyway, the part i contended and you were
    > wrong about is that just because something
    > buggy runs in ring-0, doesn’t mean it’s all lost
    > case. you believe it is, we showed a specific

    I didn’t say I believe it’s a lost case. What I don’t believe is that can always protect against everything. There are going to be coding errors, typos, whatever, that will cause bugs that can be exploited. There will be systems to defend against a lot of it, but there is always a chance that it will be bypassed. It’s something that in todays modern coding (good or bad) is a reality. It doesn’t mean we should give up, and I never said that. It means we have to be realistic about it and plan for it. Which you, I, and others are doing.

    This is going to be my last post. I’ve done some google searches and can see that this isn’t going to get any better based on similar comment threads at other blogs. I think we’ve both wasted enough of our time dancing around each other on this.

  12. David Cafaro says:

    Ok, was wrong, one last post, might be helpful if I showed how SELinux protected that kernel bug:

    http://www.redhat.com/archives/fedora-selinux-list/2006-July/msg00071.html

    I remember trying that out and seeing it work (after reading this post), but couldn’t find the thread till now.

  13. spender says:

    Has RHEL5 fixed the undocumented “feature” of ExecShield’s nondeterministic security on systems that don’t support NX? I reported the problem to Ingo at the time of Fedora Core 3, when I had also noticed that half of the processes on my system had no protection from ExecShield, due to several libraries improperly being marked with PT_GNU_STACK (which under ExecShield with no NX, means that the entire userland address space is executable). Fedora users were not notified of this. The “nondeterministic security” I refer to involves ExecShield’s behavior with PIE binaries, which it treats as just another library. Take a look at the /proc//maps files on your systems (which don’t support NX) and observe the highest mapped executable file. Nearly all of the time, this will be a library (one of many the binary has loaded).

    What most people don’t know is that the bss/data sections of all other loaded libraries, and including the PIE binary itself, are executable. SELinux’s protection to ensure that no writable buffer becomes executable means nothing here since the areas can be executed in without actually having PROT_EXEC on their vmas.

    I’ve confirmed this up to RHEL4, but don’t have a RHEL5 VM around to test on. If it’s been fixed (which I doubt), then great. Otherwise, I think this is something that people need to be aware of, instead of giving them the false idea (as is given in this article) that any writable buffer can’t be executed in.

    And BTW, ExecShield still contains a bug present since it was originally written that makes it useless against a local attacker ;) (gotta love those 5 year old vulnerabilities)

    I know it’s nice for your marketing to be able to talk about your “buffer overflow protection” but maybe less effort into marketing and more into real technology would help.

  14. spender says:

    Actually, the general problem can’t be fixed and should be noted prominently. The only thing that could be possibly fixed in RHEL5 is a decision as to what library (or PIE binary) will always be the highest in the address space, giving it bss/data protection. The writable areas in all other lower mappings will be executable (unknowingly to most users, since they lack knowledge of how ExecShield works, perhaps because RedHat’s claim that they have “buffer overflow protection” and that writable buffers can’t be executed in, makes this knowledge appear unnecessary).

  15. spender says:

    Just a couple examples of the gross ignorance on behalf of RedHat regarding their technologies:

    http://www.noncombatant.org/trove/drepper-redhat-security-enhancements.pdf

    (talking about ExecShield/reordering elf sections)
    “After all this protection is applied the memory an attacker can write to are the stack, the heap and the data section of the various loaded objects. And unless there are good reasons none of these memory regions is executable.”

    In light of my above posts, this is absolutely false.

    http://www.redhat.com/magazine/009jul05/features/execshield/

    (an earlier version of this magazine, commenting on ExecShield)
    “Segment limits provide limited control over what parts of memory can and can not be executed. For the majority of application programs this is sufficient, with protection results comparable to NX technology.

    A year ago it might have been interesting to explore the technical details of segment limits, but now that all new processors have NX support, segment limit technology is rapidly becoming a relic.”

    Nicely side-stepping the issue here, with no statistics to back up the claim that discussion of segment limit technology is useless because NX-capable processors are on the market. I guess RedHat assumes that within that past year, every user of Fedora or RHEL have upgraded their systems to a 64bit processor with NX support. Also note that there’s no discussion on what “comparable” means. Having writable/executable bss/data sections on all but one loaded library (this is often over a dozen in many applications/services) allowing for arbitrary code execution — whereas NX would not — is not something I would call “comparable.”

    Even in the official ExecShield paper:

    http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf

    again there is no mention of these problems, and in fact it even tries to compare itself against PaX (which actually does provide the same functionality as NX without the 6% performance hit of using NX (due to PAE) that you’ll find mentioned briefly in the above paper). They ignore the vma-mirroring technique of PaX which allows to provide for the real separation of executable code and non-executable data. ExecShield does not have this and sets only a limit at which all code/data residing under it is executable. Several things can change this limit (such as loading a library with PT_GNU_STACK set) which will result in much or all of the address space becoming executable without the user’s knowledge, something that never happens within PaX.

    That such a comparison was attempted to cover up the weaknesses in the ExecShield model is shameful.

    What you’re seeing is not individual mistakes but a widespread ignorance and goals of misinformation rather than honesty on the part of several of RedHat’s main developers. Since RedHat is failing in their job to properly inform their users of the security they’re being provided, I’m forwarding this article and its comments to the DailyDave/Full Disclosure lists so that the security community is aware of it.

  16. forcerain says:

    The above posts have given me reason to change distro.. I feel more and more inclined to convert my RHEL desktop to a Hardened Gentoo one. Not only is SELinux alone very complex but it isn’t covering all angles how i’d want it to.

  17. Mikel Ward says:

    There are some problems with Hardened Gentoo. I’ve encountered some non-standard patches to pam_ssh, nfs, and portmap that were all well intentioned, but caused problems in an enterprise environment.

    I feel more comfortable using a distribution that doesn’t highly modify packages.

    It would be nice if Debian had a more readily available version that supported PaX.

  18. Scott Hollomon says:

    SELinux is nice but not the product I want. Essentially I now have two sets of ACL’s that I must manage to maximize system security. ACL’s I might add that can have conflicting values and produce surprising results.

    What I want is a single security system that produces the combined results of Linux’s permissions and SELinux. Until then, until its all in one place, it’ll be a product I have to use not one I want to use. Products I have to use get dumped at the first possible opportunity.

  19. Bibo says:

    Nice article.

    But I don’t understand your example wit httpd and mysqld.
    Normally, the web server works with databases and this case the httpd has to communicate with mysqld/postgresd. If once the attacker gains access through the web server, then your database will be compromise too, because your httpd has access to mysqld. Is it true?

    Regards,
    Bibo

  20. Wayne Wolfe says:

    Thanks for the article on SeLinux which evolved into a “sales pitch” about PaX. It is unfortunate that anyone who attempts to provide information to the community at large must risk be subjected to uncivilized rants. Both Spender and the PaX Team apparently have ego issues which prevent them from participating in rational, civil discourse. I, for one, appreciate your efforts.

    Regards,
    Wayne

  21. spender says:

    Bibo: You’re right to an extent. Any kind of authentication information that can be grabbed from within apache’s address space or contained in any file apache can access can be used against mysql. In cases like website forums (like PHPbb) for example, apache needs access to the site’s config file. Contained in the config file is the cleartext password for administering the forum database, so a compromise of apache can be used to completely control the contents of that forum database. As you’ve already guessed, the separation between services isn’t as clear as RedHat’s diagrams would like you to believe.

    Wayne: I’m glad you appreciate the efforts of people who intentionally distort facts in an effort to improve their company’s image, not your security, as long as it appears to be done in a “rational, civil” manner. Did you have anything technical (or rational, unlike your ad-hominem attacks) to contribute to the discussion? Were any of my many points wrong at all? You’re forgetting history and where all these cheap security ripoffs are coming from. Can you take a guess what prompted RedHat to propose a null pointer dereference protection (while I’m here, let me throw a md5sum out: 3812e371986ad24ace67bab90fd07ca4) for Linux?

    For commercial entities, money is the bottom line. Don’t be fooled into thinking true security is of great importance. Merely the illusion of security, obfuscated through misleading graphs and half-baked solutions aimed at unintelligent hackers, is good enough — so long as everyone shuts up about the details and remains “civil,” so long as the majority of the security community isn’t laughing at them. Attempting to marginalize security experts who point out the devil in the details only helps in further enabling RedHat to continue their disinformation campaign. It’s these people you don’t like, these people that tarnish the perfect image you have of RedHat that are the ones improving your security. Here’s some reading for you (not that I think you’ll understand any of it):

    http://x82.inetcop.org/h0me/papers/FC_exploit/FC_exploit.txt

    http://fist.immunitysec.com/pipermail/dailydave/2006-November/003742.html

  22. Shakeel says:

    What kind of Modems for internet connectivity are supported?Are the Win Modems work with this release of Linux?

  23. Rod says:

    There is a typo in your command:

    grep httpd_t /var/log/audit/audit.log | audit2allow -m myhttpd; semodule -i myhttpd.pp

    Should be (with a capital -M):

    grep httpd_t /var/log/audit/audit.log | audit2allow -M myhttpd; semodule -i myhttpd.pp

  24. Jeremy says:

    I work for a large bank and was until now convinced that SeLinux was the way to go, reading all the responses to this article has definitely changed my mind, I am now back to square one in my research for a solution for our servers.

  25. Neil says:

    SELinux for CentOS 5 is extremely difficult to understand. Is there a “101” tutorial that explains the basic concepts in plain English?

  26. Dan Walsh says:

    Read

    danwalsh.livejournal.com from the beginning.

  27. Apple sandboxes further use at Useful Security says:

    […] It looks like Apple will be using sandboxes for a bit more than the current couple processes in the future (perhaps Snow Leopard). Looking at the CUPS code (CUPS was purchased by Apple in February of last year), they’ve added support for sandboxes to their development tree, which will theoretically make it into CUPS 1.4. As OS X exploits start to become available in the wild, I hope Snow Leopard confines many more applications (maybe Safari…). It’s nice to see so many major operating systems adding advanced access control features. […]

  28. Cafaro’s Ramblings » Nice Article on SELinux in RHEL5 (and some interesting Comments) says:

    […] http://www.redhatmagazine.com/2007/05/04/whats-new-in-selinux-for-red-hat-enterprise-linux-5/ […]