Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

SELinux by Example

samzenpus posted more than 7 years ago | from the read-all-about-it dept.

Book Reviews 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.

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.

cancel ×

77 comments

Sorry! There are no comments related to the filter you selected.

huh? (-1, Redundant)

mastershake_phd (1050150) | more than 7 years ago | (#18353579)

SELinux is a project started and actively maintained by the U.S Department of Defense

Why is the Government selling Linux?

Re:huh? (1)

pembo13 (770295) | more than 7 years ago | (#18353627)

I just don't see how you come to that conclusion based on the statement you quoted.

Re:huh? (1)

cyberbob2351 (1075435) | more than 7 years ago | (#18353705)

They're not, but if you would like to pay them for it, I'm sure they wouldn't mind...

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.

Re:huh? (0)

Anonymous Coward | more than 7 years ago | (#18361343)

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.

Re:huh? (3, Informative)

Kadin2048 (468275) | more than 7 years ago | (#18353707)

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/ [nsa.gov]

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? (3, Informative)

Anonymous Coward | more than 7 years ago | (#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.

Re:huh? (0)

Anonymous Coward | more than 7 years ago | (#18354739)

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." :-)

Re:huh? (2, Insightful)

kestasjk (933987) | more than 7 years ago | (#18356605)

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.
Then why not use BSD (which already is going down this road with TrustedBSD)? Why not keep the changes to yourself? (the GPL doesn't force to release the changed code unless you're distributing it)

Unclear who's to credit or blame. (3, Interesting)

Kadin2048 (468275) | more than 7 years ago | (#18356859)

Sounds suspiciously like they were hired by the NSA, and effectively sold the code to NSA as part of their contract.

From SELinux FAQ #11 [nsa.gov] :

Researchers in the Information Assurance Research Group of NSA worked with Secure Computing Corporation (SCC) to develop a strong, flexible mandatory access control architecture based on Type Enforcement, a mechanism first developed for the LOCK system. NSA and SCC developed two Mach-based prototypes of the architecture: DTMach and DTOS (http://www.cs.utah.edu/flux/dtos/). NSA and SCC then worked with the University of Utah's Flux research group to transfer the architecture to the Fluke research operating system. During this transfer, the architecture was enhanced to provide better support for dynamic security policies. This enhanced architecture was named Flask (http://www.cs.utah.edu/flux/flask/). NSA has now integrated the Flask architecture into the Linux operating system to transfer the technology to a larger developer and user community.
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 [lwn.net] , but later on decided this was a Bad Move [linuxsecurity.com] --- 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 [securecomputing.com] (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.

Re:huh? (3, Interesting)

LWATCDR (28044) | more than 7 years ago | (#18353983)

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.

Re:huh? (0)

Anonymous Coward | more than 7 years ago | (#18354533)

So now everyone that uses Linux can benefit from their research.

not to mention the terrorrist organizations!
(sorry could not resist)

Re:huh? (0)

Anonymous Coward | more than 7 years ago | (#18354021)

because you touch yourself at night.

Re:huh? (1)

cant_get_a_good_nick (172131) | more than 7 years ago | (#18356491)

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.

Monkey SE, Monkey DO (2, Funny)

User 956 (568564) | more than 7 years ago | (#18353589)

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.

Interesting (1, Interesting)

26199 (577806) | more than 7 years ago | (#18353595)

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?

Not on a home system (0)

Anonymous Coward | more than 7 years ago | (#18353759)

But some work that I did, that was to be sold to the NSA, required this of us.

Re:Interesting (0)

Anonymous Coward | more than 7 years ago | (#18353769)

Probably several million people do, since it comes with Fedora.
You might run it because you are too lazy to turn it off.
You might run it to backstop bugs in programs that deal with untrusted data, such as network servers, web browsers, email clients, and for plugins for web browsers and email clients.

Re:Interesting (3, Informative)

mcalwell (669361) | more than 7 years ago | (#18354271)

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.

Actually it's on by default in FC5/FC6 & RHEL5 (0)

Anonymous Coward | more than 7 years ago | (#18355799)

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.

Re:Interesting (5, Informative)

Introspective (71476) | more than 7 years ago | (#18356429)

You're exactly right. Only those people with enough spare time & effort would use it.

I wrote the UnOfficial SELinux FAQ [crypt.gen.nz] 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.

Re:Interesting (1)

Antique Geekmeister (740220) | more than 7 years ago | (#18359381)

I agree. And many of the people who disable it do it incorrectly, by editing their bootloader, rather than using the options in init scripts to set it to "permissive" mode and get reports of what it is detecting, then fix those and publish those fixes or get it into the software package deployments.

Re:Interesting (1)

Zathrus (232140) | more than 7 years ago | (#18357319)

Yes, it comes with distros like RHEL4, but it's not turned on.


Yes it is, and it's on by default in enforce mode. There's even been some reports (although I have not checked them) that you cannot automatically disable it via kickstart.

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.


No, the better question is -- is there anything you do where it would actually get in the way? In the two years I've been running CentOS4 I've had it bite me exactly once, and it was pretty easy to fix the issue.

What do I get out of it? Peace of mind. No, my system isn't likely to get exploited, but on the random chance someone does find a vulnerability then SELinux will limit the damage and their abilities. What's it cost me? Nothing.

Sounds like a good deal to me.

And based on watching who wants to disable it, I'd say that it's the larger organizations that run into more problems and want to turn it off. Which is ironic, but I'll happily admit that SELinux in RHEL4/CentOS4 isn't easy to administer. I hope there are better utilities in 5.

Re:Interesting (1)

sammy baby (14909) | more than 7 years ago | (#18358455)

There's even been some reports (although I have not checked them) that you cannot automatically disable it via kickstart.


I can pseudo-confirm those reports. I've installed RHEL 4 probably over a hundred times in various configurations, and I've often had problems getting SELinux to "stay dead" from the installer. The only problem is that I never really paid attention to the circumstances in which it wouldn't stay disabled, so I can't tell you if I was using kickstart or a regular interactive install.

For what it's worth, I've been doing this a long time and am an RHCE, so I'm not entirely dim with regard to this process.

Re:Interesting (1)

caillon (629714) | more than 7 years ago | (#18359295)

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.
It's enabled in enforcing mode by default in Fedora Core 6 and Red Hat Enterprise Linux 5. See how unobtrusive it is? People don't even know it's on ;-)

Re:Interesting (0)

Anonymous Coward | more than 7 years ago | (#18355631)

sorry, brain fart. What I meant was:

Probably several dozen people do, since it comes with Fedora.

Yes I run it with FC6 - because I can (5, Interesting)

Anonymous Coward | more than 7 years ago | (#18353857)

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).

Re:Yes I run it with FC6 - because I can (0)

Anonymous Coward | more than 7 years ago | (#18353957)

Just to clarify before anyone asks; I don't mean that Skype is any worse than any other binary blob. I just mean that without getting a copy of the source code you shouldn't ever trust an application and even with it you should be careful. Whilst I don't trust E-bay for the future, I reasonably believe that Skype is probably okay. By past experience I meant things like Microsoft's WGA sending information home or all sorts of other spyware.

Re:Yes I run it with FC6 - because I can (1)

moro_666 (414422) | more than 7 years ago | (#18354957)

Humm ... is this just me or is someone being slightly naive here ?

  SELinux as mighty as it may be for tracking skype and alike, it will probably not track down your perl script include tags (lets say mailfilters that run somewhere, or from another app, the "safe" javascript in mozilla ?). Yep you can tell your mozilla that it shouldn't read a or b or c nor should it write d, but how much can you restrict perl on your system ? or bash for this sake ? bash scripts are not always harmless :p will SELinux track down someone's lazy php inclusion code which fetches the code to execute over http by mistake ? and SELinux is still quite helpless against racing bugs (2 apps writing into /tmp/foobar at once and reading it from there, bot apps will follow the rules set up, but one may start to do stuff you wouldn't expect it to ...).

  Common sense is the first line of protection, if that isn't there, even SELinux won't save you. And grandmother Bethy will never understand why she would have to go through all of this SELinux mess just to feel a bit safer.

  SELinux flies over most of the dumbusers head without even the slightest buzz, they just can't track it nor keep it up, nor do they *want* to do it. FC based systems are in a way like windows machines, when they get old you install the next fc and life goes on as it would in m$ world. But some machines will have to run for years, yes you may update the kernel at times, but you'd rather not reconfigure everything again because you need a newer version of one package. If you start to upgrade stuff this will get messy and will cost time, new paths, new files, new library tricks. SELinux without the know-how how to use it, may be even a greater risk than running without it (for comfortability sake people turn too much stuff to allowed and start to lose the line of attention where when and why and as who some commands are executed, because they are "secure").

  SELinux definitely is a nice helper to control the system, but it's not a complete silver bullet, people please don't praise it as one.

 

The "safe" javascript in Mozilla (0)

Anonymous Coward | more than 7 years ago | (#18355031)

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.

Re:Yes I run it with FC6 - because I can (1, Informative)

Anonymous Coward | more than 7 years ago | (#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:Yes I run it with FC6 - because I can (0)

Anonymous Coward | more than 7 years ago | (#18355545)

Go learn about security and what SELinux does before spewing jibberish like this because you obviously have no clue.

Re:Yes I run it with FC6 - because I can (0)

Anonymous Coward | more than 7 years ago | (#18360295)

With all due respect, does anyone else see the conflict here?

It just completely doesn't get in the way... 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...

Personally I wouldn't say something which broke things, didn't give me complete information on how to fix it, and required me to learn another new tool in order to fix it, "completely doesn't get in the way".

I see this a lot on slashdot. There are always very visible comments along the lines of "Ubuntu IS easy enough for grandma", "OpenOffice.org IS fully ready to replace MS Office in a corporate environment", "it's so much simpler to maintain a linux box than a Windows one".

But, often buried a bit more, are the posts that say: "oh, right, you need to do {X} / you couldn't install because of {X} / it crashed because of {X}? Yeah, that is a problem actually. It's fixed in the trunk but if you don't want to recompile from the nightly source you could always just upgrade your libfoo, then run a quick apt-get -crypticflag -youdneverknowabout, edit your foo.conf, chmod the file x--w-r- and you'll be right as rain." And these posts tell a bit of a different story.

Now this isn't one of those annoying "slashdot is hypocritical" posts, because I do realise they may well come from different people. And even if they don't, I don't abscribe malice: I'm sure when you administer Linux every day and use Windows never (which is in itself regularly proven by comments), Linux does seem easier to maintain than Windows.

Ultimately, though, I have to say the net effect is to undermine my faith in the supportive proclamations on here. If someone says "it completely doesn't get in the way", and then proceeds to explain what they really mean is that it only broke things a little bit, and they could fix it by learning some command line tool, then the next time someone tells me Linux/whatever is "completely" invisible / reliable / intuitive / whatever, I'm not really inclined to believe it, am I?

Wouldn't it be better to avoid the false/exaggerated promises and say, "Yes, it requires some time and effort and learning, yes, it's a bit more complicated than your average schmuck's point-and-clicking, but the dividends are worth it."

Re:Interesting (0)

Anonymous Coward | more than 7 years ago | (#18360725)

I've been considering using SELinux at home on an extra computer I have to function as a secure online financial transaction appliance. The idea is, I would reduce the machine to the most minumum configuration possible, and then use the SELinux security module to allow only one application to run: Firefox. And then I would use this machine, and only this machine, for my online financial transactions. And as an added precaution, I would only connect this machine to the network when doing online financial transactions, and when doing so, I would disconnect all other machines from the network. Yes, you can call me paranoid.

SELinux is okay if... (0)

Anonymous Coward | more than 7 years ago | (#18353733)

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.

Re:SELinux is okay if... (1)

grahamlee (522375) | more than 7 years ago | (#18359597)

the log entries are recording the fact that SELinux has silently blocked access

I would like details of the logging tool you use. Mine only records details which have been logged, so far silent changes elude it.

Re:SELinux is okay if... (0)

Anonymous Coward | more than 6 years ago | (#18370189)

Oh God, a Limey. Okay, I'll type this really s-l-o-w so you can understand it.

SELinux logs to the logfile. I think I mentioned that in my previous post.

Still on the same page?

Okay then, what is it logging? That would be "That it has silently blocked access...". I think I mentioned that in my previous post, too.

There. That wasn't so hard, was it?

Is the "silently blocked access" part still troubling you? I believe that SELinux does not notify the process that caused SELinux to block the access. It just *silently blocks the access* and records the event in the logfile.

Gentoo has a good kernel hardening guide (1)

cyberbob2351 (1075435) | more than 7 years ago | (#18353799)

Check out the Gentoo hardening overview. They refer to a couple of good kernel technologies useful to secure your system if you are that paranoid.

Hardening [gentoo.org]

And keep in mind: Even if you are not paranoid, they still could be out to get you.

Re:Gentoo has a good kernel hardening guide (0)

Anonymous Coward | more than 7 years ago | (#18359147)

Isn't paranoia defined as an invalid belief that someone is trying to get you? In which case, if they ARE trying to get you, then your obviously not paranoid, regardless of whether you think that they are or not.

Re:Gentoo has a good kernel hardening guide (1)

bodan (619290) | more than 7 years ago | (#18359527)

I think the definition is more like "unreasonable belief that someone is trying to get you". For a simple example, just because a terrorist intends to, say, "kill any and all Americans" doesn't mean that all paranoids in America become instantly sane (or, at least, not paranoid anymore).

AppArmor? (3, Informative)

G Money (12364) | more than 7 years ago | (#18354081)

It seems to me that AppArmor [wikipedia.org] 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? (1)

drinkypoo (153816) | more than 7 years ago | (#18354117)

What's your take on node-based vs. path-based MAC specification?

Re:AppArmor? (2, Informative)

G Money (12364) | more than 7 years ago | (#18354241)

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:AppArmor? (2, Interesting)

Anonymous Coward | more than 7 years ago | (#18354197)

AppArmor and SELinux took two totally different approaches. AppArmor started addressing usability first, and security second. SELinux took the reverse approach. I would argue that when it comes to a security mechanism, the one with the soundest implementation would always win. But unfortunately this is not the case. But SELinux has been taking leaps and bounds to address the usability issue. Just check out SLIDE, reference policy, and FC6/RHEL5.

Re:AppArmor? (2, Insightful)

99BottlesOfBeerInMyF (813746) | more than 7 years ago | (#18354207)

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.

The truth is, the vast majority of systems don't need either, but the concept is a nice security architecture to have in place for those rare instances where it is needed and as a built in part of security going forward.

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.

If you're trying to secure a system today, you might be better of with AppArmor from what I understand. If you're trying to decide upon a MAC architecture that will be part of Linux going forward, SELinux looks like a much better bet. Ubiquitous application of MAC is a big win in the long run. Building on the best base and then creating in the tools to effectively use it seems like a wise approach to me. I foresee a time when MAC will play a vital role in securing desktop machines and I think most of the configuration woes are solvable by the addition of policies as part of applications and for application types and trust levels on a system by system basis. You don't want Joe Sixpack configuring this any more than you want him configuring a firewall, but instead it makes sense to present end users with a system that "just works" built upon SELinux.

Re:AppArmor? (0)

Anonymous Coward | more than 7 years ago | (#18360517)

...all the extra effort it takes to setup SELinux isn't needed

But who cares? It is getting mainstream and it is already included in some major distributions. The person installing such a distro won't have to mess with the policies...

SELinux is gaining lots of momentum and it's here to stay for a lloonng time.

SE....x (1)

socalmtb (235850) | more than 7 years ago | (#18354563)

Am I the only only who, because of the capital "SE", skipped the "Linu" and went straight to "x".

Re:SE....x (0)

Anonymous Coward | more than 7 years ago | (#18354829)

Yes.

Re:SE....x (0)

Anonymous Coward | more than 7 years ago | (#18355381)

no you are not, but SELinux is as hard to get as SEX for slashdotters, the only problem is this book will help with SELinuX as much as a book on sex would help. you just need someone to show you how.

Re:SE....x (0)

Anonymous Coward | more than 7 years ago | (#18357135)

No, you're not the only one. I'm also wondering what that S-E-X thing is all about.

More Infosec douchebaggery (0)

Gothmolly (148874) | more than 7 years ago | (#18354671)

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.

Don't like it (0)

krunoce (906444) | more than 7 years ago | (#18354681)

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?

Sounds like an ad (2, Interesting)

Animats (122034) | more than 7 years ago | (#18354731)

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.

Re:Sounds like an ad (1)

diegocgteleline.es (653730) | more than 7 years ago | (#18355539)

Not too much of that has happened.

You haven't run modern linux distros for a while, don't you? Linux distros have been shipping SELinux for years, and not just "for fun" - they wouldn't go through the pain of including it if they didn't use it.

Red Hat 4, which was released on February 2005 already used SELinux at least for: apache, dhcpd, mysqld, named, nscd, ntpd, portmap, postgres, snmpd, squid, syslogdm winbind. RHEL 5 (released today) probably adds more.

No, people still hasn't wrote SELinux rules for firefox. But boy, saying that "not too much of that has happened"...people has been there for years

Why I don't use SELinux (1)

Dishwasha (125561) | more than 7 years ago | (#18354887)

I would love to use SELinux but end up doing a setenforce 0 and make it permissible because of these things:

  • Ubuntu does not support SELinux without going to the world repository and I can't get the system to boot with the default policies. This is well known and is current a work-in-progress and we all know the state of SELinux in Ubuntu. Ubuntu also has a lot of upgrade issues with deprecated libraries and versioning and I end up with a corrupt system.
  • Gentoo never installs properly; too many broken repositories and bad source compilations.
  • Slackware is what I have used for years and had a fine time running SELinux and adding new policies, but the lack of decent package management made the benefit of an easy to maintain SELinux not enough of an advantage to stick with the distro.
  • Fedora Core 5 & 6 have great package management and a great SELinux default and targeted policy, but they no longer offer the policy sources since 3 (maybe 4), the documentation hasn't really been updated since 3 (spent lots of time googling), and I don't want to have to reinvent all the domains, classes, and objects that are already defined in the current policies nor can I compile new policies because of no selinux-policy-targeted-sources RPM since 3.

Re:Why I don't use SELinux (0)

Anonymous Coward | more than 7 years ago | (#18362133)

but they no longer offer the policy sources since 3 (maybe 4)

So what do you call this [redhat.com] ?

The selinux-policy-devel, selinux-policy-targeted, selinux-policy-strict, and selinux-policy-mls packages are all created from the above linked source package. You might only need the -devel package.

the department of defense runs this? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18355017)

what ever happened to the "don't ask, don't tell" policy?
 
if you didn't get it: linux is still for fags.

Just installed FC5 with SELinux turned on. (1)

suitti (447395) | more than 7 years ago | (#18355137)

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.

Re:Just installed FC5 with SELinux turned on. (1)

juhaz (110830) | more than 7 years ago | (#18360403)

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.
You might not need the book any more. The configuration has been simplified a lot in FC6, it has a daemon that monitors the log files, and a gui tool that pops up a notification whenever SELinux blocks something, and in common cases tells you what do to tweak the specific setting.

For example, I tried temporarily turning on the "don't allow apache to read home dirs", and get this if I try to access them: http://www.cc.puv.fi/~e0600613/sealert.png [cc.puv.fi]

NSA says it's not secure (0)

Anonymous Coward | more than 7 years ago | (#18355611)

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.

The nice about user/group permissions (1)

renoX (11677) | more than 7 years ago | (#18355925)

The nice about user/group permissions ... is that they don't require books of 400 pages for explanations..

my computer is completely secure (0)

Anonymous Coward | more than 7 years ago | (#18357109)

I've removed root's password and made all files world writeable so unauthorized access is impossible!

SELinux - Useable? (2, Interesting)

softcoder (252233) | more than 7 years ago | (#18356265)

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.

I want to get rid of all of SeLinux on Debian (1)

mazphil57 (792004) | more than 7 years ago | (#18356413)

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.

Re:I want to get rid of all of SeLinux on Debian (0)

Anonymous Coward | more than 7 years ago | (#18359613)

If selinux is disabled in the kernel it is not going to be used. But presumably for selinux to be supported by some applications it needs to be compiled in, making it a dependency of the application. You could try forcibly removing the the libselinux library and see if everything still works or you could recompile the applications that depend on it. Or you could ignore it safe in the knowledge that it doesn't affect anything if selinux is disabled.

Re:I want to get rid of all of SeLinux on Debian (0)

Anonymous Coward | more than 7 years ago | (#18479533)

Same here! I googled this page looking for a way to completely remove the damn thing from xubuntu (debian based version of ubuntu). If you look under dmesg its got several entries and would seriously speed up the boot process if completely removed.

SELinux is a backdoor (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18356431)

SELinux is nothing more than a hook for back door access to Linux systems. Check out the kernel source and see how easy it is for a loaded module to hook into all the important information paths in the kernel. SELinux provides a bigger security hole than that which it is supposed to plug.

Yes, but... (1, Funny)

Anonymous Coward | more than 7 years ago | (#18356791)

does it run on Linux?

oh, wait...

Solaris' Role Based Access Control Proves Unix (1)

Stephen Samuel (106962) | more than 7 years ago | (#18357783)

Solaris's heavily touted Role Based Access Control Mechanism was built upon Unix's file permissions, SU bit capabilities, limited shells, and extra user accounts that had a shell that rejected direct logins.

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).

Book is out of print? (1)

flyingfsck (986395) | more than 7 years ago | (#18358753)

I actually tried to buy this book a week ago. No luck.

can't I use PAM (1)

red crab (1044734) | more than 7 years ago | (#18359413)

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?

Re:can't I use PAM (1)

guruevi (827432) | more than 7 years ago | (#18360427)

PAM is something completely different than SELinux. PAM tries to give you pluggable authentication modules through the same interface (kinda like a general API for Unix/Linux authentication). If you are a programmer, whether the end user uses a local username, LDAP or MySQL for authentication, you have to write only 1 authentication option in your program to authenticate.

SELinux is a type of MAC architecture for Linux. It enforces the actual security on objects based on their policy, defined separately from the object. If a user creates or accesses an object, it will enforce the least privileges on the object based on the SELinux policy.

mandatory pedantry (1)

mattpalmer1086 (707360) | more than 7 years ago | (#18360013)

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".

Acronym overload (1)

pelago (957767) | more than 7 years ago | (#18360371)

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.

Two bad experiences with SELinux (1)

stry_cat (558859) | more than 7 years ago | (#18361015)

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.

Re:Two bad experiences with SELinux (1)

Embolism (703224) | more than 7 years ago | (#18361443)

I have FC6 installed. Just disable SELinux on the first boot configuration (this will trigger another reboot). I have had no problems since then. My first install of FC6 I disabled SELinux after the box was up via the config file and rebooted. Rebooting failed with (what else) a SELinux warning which halted the machine mid boot.

TOMOYO Linux (1)

toshiharu (1076837) | more than 7 years ago | (#18382073)

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 [sourceforge.jp]

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.html [celinux.org]

Abstract:

Linux has been adopted more and more by embedded devices. But its poor access control model raises critical security problems. Unlike PCs, it is difficult to apply security patches to embedded devices. Thus, embedded devices should be designed with due consideration for imperative access control. Linux kernel 2.6 has been equipped with LSM (Linux Security Modules, OS level security framework) to provide MAC (Mandatory Access Control, imperative access control) ability. NSA's SELinux (Security-Enhanced Linux, LSM applicant security server) provides very fine-grained access control, but its requirements for embedded devices seem to be too excessive. LIDS (Linux Intrusion Detection System), on the other hand, is relatively compact and better suits embedded systems. However its access control granularity is rather sparse. There are many limitations which are specific to embedded devices. For example, slow CPU speed, storage capacity for OS and programs, filesystem that doesn't support xattr (extended attributes), hard-links and symbolic links used for busybox (multi-call binary to save space), files dynamically created on volatile filesystem. TOMOYO Linux (http://tomoyo.sourceforge.jp/index.html.en) is yet another way to provide a lightweight and manageable MAC ability. It is available under GPL and applicable to and suitable for both PCs and embedded devices. In this session, we will present an overview of TOMOYO Linux and explain why TOMOYO Linux is suitable for embedded devices. We will also show some demonstrations.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>