Slashdot Mirror
SELinux by Example
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 linuxhelp.blogspot.com where he shares his thoughts and experiences on all things related to Linux.
You can purchase SELinux by Example from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
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 linuxhelp.blogspot.com where he shares his thoughts and experiences on all things related to Linux.
You can purchase SELinux by Example from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
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.
You can say that, sure, but I think for most people, SE'ing is believing.
The theory of relativity doesn't work right in Arkansas.
But is it useful? For military and some business use, I can see it... but does anyone actually run SELinux on a home system?
If so -- why?
I just don't see how you come to that conclusion based on the statement you quoted.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
In that case actually, I'm selling SELinux for half off what the government charges. Interested in a purchase of some ISO's? I have some mirrors I can point you to if you send me a paypal payment of $500. Technical support will be handled over IRC on freenode.
for sale
I'm a self-modifying sig virus
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:
http://www.nsa.gov/selinux/
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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
SELinux is okay if you want your logs filled with line after line of sh*t.
Every distribution I've used has never been able to fix this. Oh yea, the log entries are recording the fact that SELinux has silently blocked access to something that the system needs to do. I don't think my Fedora 5 has ever been able to write back to the BIOS hardware clock because SELinux thinks it shouldn't.
Just disable SELinux - you'll be glad you did.
But some work that I did, that was to be sold to the NSA, required this of us.
Hardening
And keep in mind: Even if you are not paranoid, they still could be out to get you.
for sale
I'm a self-modifying sig virus
Yes, I selinux it with FC6. For several reasons. Firstly because I can; It just completely doesn't get in the way. I've come across a two policy things I had to change; in both cases the built in tool warned me about them, so I knew it was an SeLinux problem and didn't spend ages serching. Secondly, in both cases it gave me reasonable (but not complete) information about what to to to fixi it and finlally, if you learn how to use audit2allow all my problems were really easy to fix (and if you report them with audit message RedHat does a fix which gets rid of them in future almost immediately anyway).
Secondly I have a few servers on my system, it's nice to know that there is a reasonable chance they won't break my desktop if they get hacked into.
Finally, I have several proprietary applications I use (e.g. Skype) given past experience, I don't trust these not to do bad things like sending of my private data. Making an SeLinux policy lets me control which data these applications have access to.
Generally, running SeLinux just gives more of a feel of having control over what your programs are doing on your computer. Without it, you can limit programs from one UserID to the next, but there's no easy way to limit access within a UserID (well; chroot, but that's not really easy).
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.
They are selling nothing.
The NSA wanted to do research into making a more secure Operating System. This is part of their mission. So instead of starting from scratch or trying to get access to the source of a proprietary OS they looked around and found an Open Source operating system called Linux. They had the source and an access active development community. When their research was done they released it back to the community just as the GPL says one should.
So now everyone that uses Linux can benefit from their research.
Just like NASA, NOAA, or any number of government agencies.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
because you touch yourself at night.
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.
not to mention the terrorrist organizations!
(sorry could not resist)
Am I the only only who, because of the capital "SE", skipped the "Linu" and went straight to "x".
Great, its an article about SELinux. Now every Infosec fucktard who got his CISSP from a cereal box will be issuing memos & whitepapers about how everything at work has to run SELinux.
I want to delete my account but Slashdot doesn't allow it.
Isn't SELinux that thing that makes applications NOT WORK and you must always remember to disable it when installing linux distributions that include it?
Seriously, did SELinux ever get any easier to configure?
Hell, it is an ad. Read the last line of the article.
SELinux is a great idea, but almost nobody gets it. NSA wrote it so that commercial and open source application developers could get accustomed to writing programs that would work on a system that enforced mandatory security. The hope was that, for example, Firefox and Apache would be modified to work well under very restrictive security models, so that if some app misbehaved, its damage would be limited. This was the first step in getting out of the mess we're in now with patch-based insecurity.
Not too much of that has happened.
lol. "Yes, you can sue us, but remember we're legally allowed to spy on you, call you terrorists and send in the CIA assassins who don't exist to visit you. So go right on ahead." :-)
You're right to worry about JavaScript in Mozilla. But that's why people made the noscript extensions, not to mention safe history and safe cache to block other sneaky tricks.
Believe me, I got good use out of these three after some bastard site (which, ironically, was supposed to have documentation on Windows kernel APIs) decided to try and infect me. Of course, seeing any popup windows at all is a sure way to raise my suspicion, so it didn't last long.
Maybe I'm paranoid, but I've never suffered any serious breaches of security, either.
Fedora Core 5 gives you the option of turning SELinux on or not. I had no prior experience with it, and decided to see how bad it is. All security is bad. Sometimes, you have to live with it. I was not able to get user home directories to work in Apache. The error logs were unrevealing. Turning off SELinux fixed everything. (Google suggested i try that. Google knows everything, though some of the things it knows are wrong.)
So, before i can turn SELinux back on, i have to go through the SELinux learning curve. A book like this could help. I've not yet looked for on-line docs.
-- Stephen.
I really wish people would read the FAQ on this thing at the NSA website before trying to say this add-in makes Linux secure. The question: Is it secure? There's a paragraph for an answer, but the most telling setence: Security-enhanced Linux is only intended to demonstrate mandatory controls in a modern operating system like Linux and thus is very unlikely by itself to meet any interesting definition of secure system.
In other words: There's a lot that needs to be done before anyone can call Linux secure and SE is not the total answer, it's only one small piece. The bigger issues come about in proving it's security.
There are several distributions which have SeLinux on by default. RedHat has been putting much effort into making it completely transparent to the normal user. This does mean some loss of security (their normal user account is completely "unconfined") and so Mozilla is free to cause damage to the user's account (as another poster pointed out earlier), but it allows gradual security improvement as they reduce privilages nobody needs in normal operation.
In future what would be possible and great would be a segmented web browser with the network connecting / browsing part having access to only one directory and a much smaller simpler program checking files deposited there before copying them elsewhere on the user's request. There are many ways to split this up (e.g. the rendering engine is a separate process from the gui part and rednders direct to a frame buffer). Using selinux each of these parts can be protected from the other even though they are processes belonging to the same user.
Some of this is similar to what is already being proposed for the "one laptop per child" project, but with even finer granularity possible.
The nice about user/group permissions ... is that they don't require books of 400 pages for explanations..
There is a GUI.
h anced-linux-gui-frontend.html
http://unixhacks.blogspot.com/2006/11/security-en
I am running a Centos 4 system, with SELinux active. Since it is a web server box, I want it secured. Centos 4, is about Fedora 3 vintage when it comes to SELinux, and my config is about 2 years old. I hope that the current state of SELinux has improved a lot since then but it is hard to tell.
One thing you DO NOT need if you are trying to run SELINUX is 400 pages of abstract security theory and discussions on the 'flask' model etc. etc. There is way too much info of that sort out there and not nearly enough about the simple stuff that everyone wants to do such as enable user home directories in Apache.
I have managed, with some paid help, to get Apache to work, because it just uses files, and there are utilities to change the security context on files etc.
I have not managed to get SPAM ASSASSIN to work with Postfix, because SELINUX refuses to allow the two programs to setup a link over a port, and in my vintage, there are no utilities that allow me to change the security context of a port easily.
As for 'Downloading the Kernel Headers' and 'Writing a new Policy' then 'Compiling it' FUGGETADABOUTDIT! not going to happen with the level of technical expertise I have or the time I have.
Bottom line: SELINUX is useable, but only for systems that implement standard, simple services, and for distros that are bundled with it such as Fedora. Ubuntu? I would not want to try to integrate it into Ubuntu myself.
As for this book it sounds like it might be out of date already, and spend too much time on explaining what SELINUX is and not enough time on how to make it work.
It seems to be installed as a "required" package in a minimal install (debootstrap). When I do 'apt-get remove libselinux1' it wants to remove most of the packages on my system (xorg, etc.). Other posts seem to indicate they are not running some of it, but I want to run NONE of it.
1) it's a linux project, not a Linux Distro. It's a security adjunct to Linux.
....
umm, ok, so why is there a government linux project?
2) Hacking has gone from the script kidd13z messing with n00bs to a huge business of DOS and industrial espionage. Its really hard to mandate security, but if you make it simple and easy to use, you might make things more secure.
// MD_Update(&m,buf,j);
does it run on Linux?
oh, wait...
From SELinux FAQ #11:Not sure I have a lot of sympathy for the SCC people; they got paid for what they delivered, and then the client decided to open it up.
It's not really clear what happened afterwards; it sounds like SCC might have threatened users of SELinux with their patents, or prepared to, but later on decided this was a Bad Move --- it's not clear whether the NSA had a hand in convincing them of this, or it was a result of negative publicity from the Linux community, or what, but they eventually put out a statement (PDF) to the effect that they wouldn't use their patents against users of the GPLed code.
Hard to unravel what the real story was at this point, or how much credit should go to SCC versus the NSA for cracking heads and getting the patent threat removed, but the ultimate outcome was certainly a positive one. But at any rate, since the NSA folks were the ones who ported it to Linux from the research OS, and turned it from an academic curiosity into something with practical applications, I'd say they deserve the lion's share.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I've removed root's password and made all files world writeable so unauthorized access is impossible!
As of 2 years ago, there was little, if nothing that RBAC did that wasn't available to a well-tooled sysadmin on a normal UNI*X box (without SELinux capabilities).
Free Software: Like love, it grows best when given away.
I actually tried to buy this book a week ago. No luck.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
I don't know about SE Linux very well but just wanted to know that whether I can accomplish the same things which SE Linux does using PAM?
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.
A small point, but the access control in Windows is also called "discretionary". They are different models, but they are both discretionary.
One way of thinking about this is that mandatory means "access controlled by a mandatory policy" and discretionary means "access controlled at the discretion of an owner".
It's a shame that MAC also refers to Mandatory Access Controls. MAC already means Media Access Control, as in MAC Address. And when I ask someone to tell me their MAC address so I can register them on the network, they sometimes say that they have a PC not a Mac, so it already has at least two IT meanings. What with the new meaning of KVM, it's all getting a bit confusing.
I will never ever use SELinux. I've had two very bad experiences with it. As far as I'm concerned I'll take malware over it.
First problem. I had a shiny new install of FC3. I try to get apache to start serving webpages. It only works in one directory. The folks at fedoraforum.org were useless as usual. A couple of posts on an apache email list had me remove the php, apache, and mysql rpms and reinstall from source. After a week of nothing working, I finally stumbled upon some vague reference about SELinux could cause my problem. I was on the right track, but fixing the SELinux policy was almost impossible and I had to just disable it.
My second problem happened right after I upgraded to FC5. The first boot, it claims it needs to do an SELinux relabel. WTF? 5 min later it finally finishes the bootup. However even root can't login to the box. Box is destroyed. A few days later, somehow I managed to get into the single user mode, I found that the config file still had SELINUX=disabled in it. So now SELinux was ignoring its own config file! The only way I could finally disable it was to go into grub and put the selinux=0 into the boot line. I'm scared to death to upgrade to FC6. What happens with SELinux ignores the boot line? If there is an option to take it off my system when I upgrade, you bet I'll take it.
I'm actually putting off upgrading. I'm looking for a distro that doesn't use SELinux. I've been using RH since 6.1, but this SELinux thing is probably the straw that broke the camel's back.
if you would like to pay them for it, I'm sure they wouldn't mind...
I DO pay for it. Every April 15.
The NSA wasted 2 million dollars for this crap, when they could just use "jail" for free and have a superior product, to boot.
Hi,
If you think SELinux is too much/heavy for you, you might be interested in TOMOYO Linux. I'm so sure that most of you never heard of "TOMOYO Linux", so I'll explain briefly. "TOMOYO Linux is a project started and actively maintained by the Japanese SI company, NTT DATA CORPORATION to provide a Mandatory Access Controls mechanism in Linux."
In short, TOMOYO Linux is quite similar to AppArmor and has been available at SourceForge.jp under GPL license since Nov. 2005.
TOMOYO Linux Project
The project has a pleny of documentation but most of them are written in Japanese. I have some links.
If you happen to have a chance to attend CELF Embedded Linux Conference 2007 (April 17th-19th , San Jose), you'll be able to see presentation and tutorial.
http://www.celinux.org/elc2007/sessions.htmlAbstract:
Toshi