Please create an account to participate in the Slashdot moderation system


Forgot your password?
Book Reviews Books Media

SELinux by Example 77

Ravi writes "SELinux is a project started and actively maintained by the U.S Department of Defense to provide a Mandatory Access Controls mechanism in Linux. It had been a long standing grouse of Linux power users and system administrators over its lack of fine grained access control over various running processes as well as files in Linux. While Solaris touts its famous RBAC and Microsoft Windows has its own way of providing finer rights to its resources, Linux had to put up with the simple but crude user rights known in tech speak as discretionary access control to control user access of files. With SELinux project making great strides and now being bundled with many major Linux distributions, it is possible to effectively lock down a Linux system through judicious use of SELinux policies. SELinux implements a more flexible form of MAC called type enforcement and an optional form of multilevel security." Read the rest of Ravi's review.
SELinux by Example
author Frank Mayer, David Caplan, Karl MacMillan
pages 425
publisher Prentice Hall
rating 8
reviewer Ravi Kumar
ISBN 0131963694
summary This book imparts a deep understanding of the features, structure, syntax and working of SELinux

The book SELinux by Example is authored by three people — Frank Mayer, Karl Macmillan and David Caplan and is published by Prentice Hall. There are a total of 14 chapters and 4 appendices spread just over 400 pages. The 14 chapters are in turn broadly divided into three parts with the first part containing chapters which provide an overview of SELinux, its background and the concepts behind it. The second part contains 7 chapters which are most useful for SELinux policy writers and contain detailed explanation of the syntax used in writing the policy files. It is the third part, "Creating and Writing SELinux Security Policies" which could be most put to use by system administrators.

In the second chapter, the authors introduce the concept of type enforcement access control, the understanding of which is imperative to ones knowledge of SELinux. They further discuss the concept of roles and multi level security. True to the title of the book, all these concepts are explained by analyzing the security controls of the ubiquitous passwd program.

In the succeeding chapter the authors explain the underlying architecture of SELinux. More specifically, how SELinux integrates with the Linux kernel via the Linux security module (LSM), the organization of the policy source file and how to build and install policies.

SELinux policies to a large extent are based on object classes. For example, you can create an object class and associate a set of permissions to that class. All objects associated with that class will share the same set of permissions. In the fourth chapter, one get to know about different types of object classes and the permissions that can be assigned to these classes. A total of 40 classes and 48 permissions are discussed in this chapter.

The next chapter titled "Types Enforcement" goes into a detailed analysis of all the types and attributes as well as the rules that could be used. The majority of SELinux policy is a set of statements and rules that collectively define the type enforcement policy. Going through the chapter, I was able to get a fair idea of the syntax used in writing TE policies.

Keeping in mind the complexity of the subject, it helps a great deal that at the end of each chapter there is a summary section where the authors have listed the important points covered. More over, one gets to answer a couple of questions and check one's knowledge about the topic being discussed.

In the 6th chapter, the authors explain in detail the concept of roles and their relationship in SELinux. What I really like about this book is the fact that each concept of SELinux has been dedicated a chapter of its own. For instance, constraints, multilevel security, type enforcement, conditional policies,... all are explained in chapters of their own.

One thing worth noting is that Fedora Core 4 and RHEL 4 and above ship with the targeted policy by default. Where as to completely lock down a Linux machine, you need to embrace the strict SELinux policy. This has the side effect of causing breakages with some of the existing Linux applications which expect looser security controls. In targeted policy, the more confining rules are focused on a subset of likely to be attacked network applications. In most cases, one can manage by using targeted policy. This book mostly deals with the strict policy of SELinux and in chapter 11, the authors dissect the strict example policy maintained and updated via the NSA and Fedora Core mailing lists.

There is another policy called the Reference Policy which is an attempt to water down the strict policy maintained by NSA. In the process making it easier to use, understand, maintain, and more modular. This is covered in the succeeding chapter titled "Reference Policy".

The next chapter titled "Managing an SELinux system" is one which the system administrators will relate to, where the authors throw light on the hierarchy of SELinux configuration files. The purpose of each file is explained in simple terms. Considering that SELinux comes bundled with a rich set of tools meant to be used by system administrators, one gets to know the usage of some of them and also learn about the common problems that are faced by administrators while administering an SELinux system.

In the last chapter of the book, one is introduced to the task of writing policy modules. Here the authors hand hold in the creation of a policy module for the IRC daemon for Fedora Core 4, from the planning stage to writing and applying the policy module, to the final testing.

The book also includes 4 appendices which contain a wealth of knowledge on SELinux. I especially liked appendix C which lists all the object classes and permissions as well as appendix D which has a list of SELinux system tools and third party utilities with explanations.

I found that I was better able to assimilate what the authors explained when I read the 13th chapter of this book first and then went back to read the 4th chapter onwards. Having said that, I find this book to be an excellent resource for people interested in developing SELinux policies and to a slightly lesser extent a resource for system administrators. At the very least, this book imparts a deep understanding of the features, structure, syntax and working of SELinux.

Ravi Kumar maintains a blog at where he shares his thoughts and experiences on all things related to Linux.

You can purchase SELinux by Example from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

SELinux by Example

Comments Filter:
  • Re:huh? (Score:4, Informative)

    by Kadin2048 ( 468275 ) <slashdot,kadin&xoxy,net> on Wednesday March 14, 2007 @04:34PM (#18353707) Homepage Journal
    Why is the Government selling Linux?

    They don't; they give away the source code and it's been migrated into other distributions.

    SELinux was started by the NSA, and they have a page about it here: []

    They are pretty clear in their FAQ that SELinux was produced essentially as an internal product / demo, and they just thought other people might find it a useful starting place for securing Linux. They're not actively marketing it as a product, or even evangelizing it.
  • Re:huh? (Score:3, Informative)

    by Anonymous Coward on Wednesday March 14, 2007 @04:56PM (#18353969)
    SELinux was produced essentially as an internal product / demo

    The devs at Secure Computing, who wrote much of the code and who hold several patents covered by SELinux Type Enforcement, would beg to differ on this point. While they (grudgingly) accepted the release of SELinux, probably due to business concerns associated with suing a major and prestigious customer such as the NSA, they have never been all that happy about the open availability of the core concepts of their firewall product.
  • AppArmor? (Score:4, Informative)

    by G Money ( 12364 ) * on Wednesday March 14, 2007 @05:02PM (#18354081) Homepage
    It seems to me that AppArmor [] is still a much more suitable tool for MAC under Linux for 99% of the systems that need it. Unless you have very complex security requirements and are defending national secrets, all the extra effort it takes to setup SELinux isn't needed. By taking the approach of hardening the weakest points of the system (network applications, processes that run as root, etc...) you can gain almost all the security benefits without having all the added complexity. And yes, as a disclaimer, I know many of the Immunix crew behind AppArmor and have worked with them at Defcon and such. Having used both SELinux and AppArmor I can say there's no comparison in terms of effectiveness. If a security tool it too complex to use it will be used incorrectly and can lead to even worse security problems. I would rather stick with a much simpler approach that still provides all the confinement of MAC but only where I need it.
  • Re:AppArmor? (Score:3, Informative)

    by G Money ( 12364 ) * on Wednesday March 14, 2007 @05:16PM (#18354241) Homepage
    With path based you do open yourself up to problems with evil people doing things with links and whatnot but the general idea of AppArmor is that you wouldn't let someone get that far in the first place, or if you did, they belonged there. Node based eliminates that problem but opens up a new set of issues in terms of backing up filesystems (many commercial and even some open source backup solutions are brain dead when it comes to preserving extended information from the filesystem and will just ignore inode data they don't know how to handle).
    One of the cooler things you can do with AppArmor is create multiple links to a shell (they call it rbash I think) and then creating a profile for each link to a shell (i.e., ln /bin/bash /bin/rbash). You can give someone uid 0 but if their login shell is /bin/rbash they're confined to whatever binaries and directories you've limited them to in the policy. It makes it very easy to give out administrative roles to users. But if you access a system through some means not confined by an AppArmor policy and have the appropriate access, sure, you can do all kinds of badness with links. The best defense against that is to profile every entry point so that no one can create links who shouldn't be able to. Inheritance goes a long way towards making that achievable.
  • Re:Interesting (Score:3, Informative)

    by mcalwell ( 669361 ) on Wednesday March 14, 2007 @05:18PM (#18354271) Homepage
    It's unlikely that you would ever be running SELinux without knowing it. Yes, it comes with distros like RHEL4, but it's not turned on. I bought a book on it, read the first two chapters, and then realised that I'd never really be able to single handedly use a system, administer it and run SELinux. There's nothing I do that's worth the effort. Maybe for bigger organisations with more important data and bigger budgets, but right now I can't see it.
  • by Anonymous Coward on Wednesday March 14, 2007 @06:40PM (#18355373)
    Am I being slightly naive? Well; my primary argument is that the cost is low so it's worth doing. As far as php and perl include problems go, that's exactly where it's value is greatest. In the default FC6 (Fedora Core 6) configuration, the normal user is mostly unprotected but each server runs in a largely isolated selinux domain. When someone compromises your web script, they can compromise the web server to some extent, but that extent is much less than even just the access of the apache user.

    If, on the other hand, you have a set of specific scripts you want to run, it's possible to isolate them further. Have them transition to their own domain and don't give them access to anything other than their own limited set of files and ability to continue writing to the pipe back to apache. E.g. your comments accepting script could only write to the comments file (not even read) and your comments display script could only read. No other files on the system would be accessible to them.

    In this case, and assuming no bugs in SeLinux, your PHP include mistake is pretty limited in danger. It can take CPU time; it can make more comments (did you remember ulimit :-) and it can try sending junk back to apache or the end user's web browser, but it can't influence or even read any other files on the system no matter what mistakes it contains. It also can't make any network connections etc.

    This means you can improve the security of application that you really don't understand. That's a pretty valuable security improvement.
  • Re:Interesting (Score:5, Informative)

    by Introspective ( 71476 ) on Wednesday March 14, 2007 @08:12PM (#18356429) Homepage
    You're exactly right. Only those people with enough spare time & effort would use it.

    I wrote the UnOfficial SELinux FAQ [] and I'll tell you what the most common search query that Google sends to that page, its "disable selinux". About 80% of the hits to that FAQ are from people wanting to know how to disable it.

    Lots of people like the MAC idea, and they're keen to try it out. But its causing pain - its hard to understand and it stops stuff from working. The majority of people out there, even the open source boffins, just don't have the spare time to figure it out and work with it.

    Despite this, the SELinux by Example book is good. If you're developing software which you want to run on an SELinux system the book will help you a lot in showing you how to write the policy for your package. In fact, if you want to do serious work with SELinux then you pretty much need this book. Any online documentation you can find is likely to be very old and of little use.

Thus spake the master programmer: "When a program is being tested, it is too late to make design changes." -- Geoffrey James, "The Tao of Programming"