SELinux and Fedora

By Jake Edge
July 9, 2008

Red Hat has undoubtedly done more to make SELinux usable than any other organization, but has it actually reached the point where it can be enabled by default for all desktops? The Fedora project clearly thinks so. Not only is SELinux enabled, but the installer no longer has an option to disable it or to put it into "permissive" mode. Most of the posts in a thread on the fedora-devel mailing list see that as the right choice, but some are not so sure.

Jon Masters started things off by making a request to restore the installation option, giving several reasons summing up with:

But there are numerous other justifications I could give, including my personal belief that it's absolutely nuts to thrust SE Linux upon unsuspecting Desktop users (who don't know what it is anyway) without giving them the choice to turn it off.

His reasons were unconvincing to many as he was not considered to be a "normal" desktop user; the things he was doing were much more technical than the users that are being targeted by the SELinux policies distributed with Fedora 9. The problems he reported were resolved quickly, but the fact remains that there are paths through Fedora—even just using desktop applications—that will result in SELinux-caused failures. The Red Hat SELinux team is very responsive, but users will get frustrated quickly if things they are trying to do fail in mysterious (to them) ways.

Alan Cox argues against providing an installation choice because he doesn't think users have enough context to make a sensible choice. He likens it to a car with multiple choices for safety features:

"This car has brakes, enable them ?"
"Would you like the seatbelts to work ?"
"Shall I enable the airbag ?"

When push comes to shove, Masters and a few others see the default of SELinux installed in "enforcing" mode as being too restrictive. It is likely to cause users to become annoyed with Fedora as a whole because one or more paths through the applications have not yet been tested. That, unfortunately, is the crux of the issue: SELinux policies are being developed in a reactive manner based on testing applications and adding exceptions for actions they perform.

As a security tool, SELinux is a good choice, because it essentially denies everything by default. Policies are added that will allow certain actions for users and applications. Its complexity is legendary, however, which is why Red Hat (and others) have made a substantial effort to make it work semi-invisibly. They started by generating policies for network-facing services and have now moved into securing desktop applications, particularly programs like web browsers which are increasingly the target of attacks.

SELinux has three modes, disabled, which turns off SELinux, permissive, which just logs attempts to do things that violate the policies, and enforcing, which disallows any access that is denied by the policies. When getting applications to work with SELinux, permissive mode is typically used. The log messages are analyzed to determine what changes should be made to the policies or to the application so that they work together. If there are features that were not tested in the application that require additional privileges, the first user that tries that feature in enforcing mode will run into trouble.

When that happens, SELinux can be put into permissive mode with a simple GUI or configuration file change, followed by a reboot. One of the problems is that users may very well not know that SELinux is the source of their problem. There are tools, like SETroubleShoot, that can help alert users, but it is still a frustrating, hard to comprehend problem at times. Once the user has "fixed" the problem by disabling SELinux, they are unlikely to turn it back on.

It is a difficult choice, but Fedora is firmly on the side of forcing non-technical users into using SELinux, at least until it breaks. More technical users will know about SELinux and, perhaps, be able to make more informed choices. One of Red Hat's SELinux developers, James Morris, neatly sums up the reasons it is important to continue pushing SELinux:

The only way to really make progress in improving security is to make it a standard part of the computing landscape; for it to be ubiquitous and generalized, which is the aim of the SELinux project.

[...] Punting the decision to the end user during installation is possibly the worst option. It's our responsibility as the developers of the OS to both get security right and make it usable. It's difficult, indeed, but not impossible.

There are efforts underway to add easier ways for users to report SELinux log messages, perhaps even in an automated way, so that policy or application problems get identified and fixed more quickly. While it may not be easy for long-time Linux users to adjust to an SELinux-enabled system, it is getting to the point where average users, who never use the command line, rarely run into problems. And those are just the kind of users who need the level of security that SELinux can provide.

Index entries for this article
Security	Distribution security
Security	Security Enhanced Linux (SELinux)

to post comments

SELinux and Fedora

Posted Jul 10, 2008 2:47 UTC (Thu) by jmorris42 (guest, #2203) [Link] (8 responses)

Somebody needs to inform Mr. Cox that when the automakers used his reasoning and turned on the
airbags with no option to turn them off a lot of people, mostly children and smaller women,
DIED.  That is why all new vehicles (at least in the US, perhaps the UK government prefers to
keep killing people in the name of political doctrine) have airbag kill switches for the
passenger seat.

So yes safety features do need to consider balance.  I know I tend to switch the damned thing
off after the first couple of failures, because in enforcing mode most machines are useless
and in permisive /var/log/messages is useless because of the noise.  Too much junk in the logs
can cause other problems to be missed.

SELinux is great if you are building a server running a locked down set of processes and your
use happens to actually run under SELinux with only a few rounds of the SELinux Troubleshooter
giving out incomprehensible incantations to say at a root terminal, reboot and try again.

I have been running Linux/UNIX/OS-9 since the freaking 80's and totally understand the UNIX
security model, but SELinux is so alien to UNIX thought  that I haven't a clue how to modify
it.  I even tried wading through the O'Reilly SELinux book and just didn't get it.  I suspect
that I'm not alone.

Kill switch is there

Posted Jul 10, 2008 6:57 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

You can disable SELinux for postgresql or mysql or any other program - that's your "airbag kill switch for the passenger seat". The installer option is more like "do you want to remove all airbags from the car - forever?" and I know no automakers who offer such an option.

Kill switch is there

Posted Jul 10, 2008 14:45 UTC (Thu) by jebba (guest, #4439) [Link] (1 responses)

> "Shall I enable the airbag ?"

If it prevents me from putting the car in gear, no thx.

Kill switch is there

Posted Jul 10, 2008 17:52 UTC (Thu) by JoeBuck (guest, #2330) [Link]

I've been running my machines at home with SELinux enabled for years. I've occasionally had a problem, but overall it's gone rather smoothly. About a year ago I needed to disable SELinux for about a day until the Fedora folks fixed a problem. I've learned enough about how the labels work that I can fix simple issues.

It doesn't prevent you from putting your car in gear.

And it's still easy to turn off from the command line. Users who are going to stick to the GUI can run with the policies Fedora ships, and they work.

Safety features

Posted Jul 10, 2008 12:05 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (3 responses)

Actually most cars that I've seen simply have a sticker which says something like "Danger: Air
bag fitted:: Do not use rear-facing child seats" and the government produces pictographic
instructions which are mandatory for new child seats that show the best place to put them (in
the back of the car, it's amazing how many parents somehow can't figure that out) and how to
correctly fit them, plus the explicit warning about not using them in the front. There have
never been suitable restraints in the front of a car to have a baby or young child next to you
while driving, (hint: it will still be there when you arrive, and whatever it's screaming
about you won't be able to do anything about it while driving) so don't do it unless its an
emergency.

It's true that US drivers love to disable safety features, often by removing the relevant fuse
or micro- circuit breaker. I'd assumed this was part of the same culture that causes them to
fight seat belt laws, drink drive laws etc. a sort of misplaced devil-may-care frontier thing.

As to SELinux, I haven't found it a large obstacle. My colleague on the other hand seems to
have no end of problems, I think it's about how you approach security problems. My approach
agrees with that of SELinux, whitelisting, safe-by-default, assume unknowns are bad etc. while
his is constantly in conflict with it, he'd rather blacklist things once he sees why they were
bad, and so on. He gets things done faster, but they break more often (and often in ways that
have potential security consequences).

I found out the other day that he hates the safety interlock delay on washing machines. I was
very happy when I found out about that delay as a teenager (doing my first load of washing and
of course reading the manual), it seemed like a sensible way to avoid potentially dangerous
interactions between operator and machine, but to him it's apparently a constant source of
frustration.

Safety features

Posted Jul 13, 2008 10:16 UTC (Sun) by modernjazz (guest, #4185) [Link]

To both jmorris42 and tialaramex: can we please keep the cross-Atlantic 
sniping out of technical discussions? Accusing the British government of 
indirectly killing children for idealogical reasons is outrageous and 
inflammatory---in addition to being wrong and grossly unfair, the 
seriousness of that charge goes so far beyond what is needed to make the 
point that it derails the whole discussion.

Similarly, blaming an "American frontier mentality" for technical 
concerns about airbags that in fact do go well beyond babies in child 
seats is misinformed and reactionary. There are indeed circumstances 
where doing something to disable the airbag on your car is the best thing 
you can do for the safety of even young/small adults.

Safety features

Posted Jul 14, 2008 10:23 UTC (Mon) by paulj (subscriber, #341) [Link]

it's amazing how many parents somehow can't figure that out

Some parents may have 2 or 3 children who are too old for baby seats, but too young/small to be allowed to legally sit in front seat (least, without additional specialised seat restraint systems) and so, out of convenience or neccesity, must use the 2 or 3 rear seats, leaving the front seat as only option for baby seat..

Safety features

Posted Jul 21, 2008 12:12 UTC (Mon) by ekj (guest, #1524) [Link]

Except offcourse, if you've got multiple kids.

We've got 3. We've also got a reasonably small car. (It's not as if we -knew- we'd get twins,
ok ?)

End-result ? The only practical way of transporting the three of them to childcare is having
the older one infront next to me, and the smaller twins in the back. 

Offcourse a kill-switch for the passenger-airbag was a $75 fix, so it's not a big deal. Just
saying there -are- legitimate reasons for having a small child in front, sometimes.

OMG! Won't someone please think of the children?!

Posted Jul 10, 2008 12:58 UTC (Thu) by ofeeley (guest, #36105) [Link]

It's always possible to twist an analogy or metaphor out of shape in order to miss its intent. Further on in the discussion[1] Alan Cox likens the discussion of whether or not SELinux should be on by default to what used to be the controversial topic of enabling firewalls by default. A lot of people's work was complicated and interrupted by the addition of firewalls yet I doubt many would wish them to either be less commonly deployed or presented as a confusing choice to novice users at installation time.

The fact is that there IS a kill switch (to use your metaphor) for those that know what they're doing. No one is arguing that SELinux should be made impossible to disable, just that there should not be the equivalent of a button on the dashboard that says "Press to stop the irritating sound that indicates your airbags are malfunctioning. You may then continue on your merry way."

The article also misses out on mentioning the rapid, copious help that seems to emanate from Dan Walsh and the other SELinux devs with fixing policies when bugs are filed in bugzilla.

1. Fedora Weekly News #133 - SELinux Eats Babies, Confines Wives, Gives Birth

SELinux and Fedora

Posted Jul 10, 2008 2:49 UTC (Thu) by jwb (guest, #15467) [Link] (8 responses)

I recently ran into this.  Having never used RHEL before, I was forced to use it on a certain
postgres server.  I installed the machine with some postgres files on one device, and some
others on another device, and a symlink pointing between the filesystems.  I could not get
postgres to start, even though I've installed it that way dozens of times.  All I saw were
"permission denied" messages in the log file, but when I checked the file permissions
everything was normal.  I even checked getfacl to see if there was some mystery ACL standing
in my way.

It was many hours before I found out that SELinux, for reasons unknown to me, does not allow
the traversal of a symlink between filesystems.  Needless to say, I completely disabled
SELinux on that machine.  I'm a 10-year veteran of Linux system administration and that
SELinux policy cost me half a day and a good deal of frustration.  The benefits, if any, of
SELinux are not obvious.  I'd be inclined to disable it by default unless customers are
actually out there clamoring for this hassle.

SELinux and Fedora

Posted Jul 10, 2008 3:34 UTC (Thu) by cventers (guest, #31465) [Link] (6 responses)

It was many hours before I found out that SELinux, for reasons unknown to me, does not allow the traversal of a symlink between filesystems.

I'd be extremely interested to know why this is... I have never heard of this before.

SELinux and Fedora

Posted Jul 10, 2008 5:49 UTC (Thu) by jwb (guest, #15467) [Link] (5 responses)

It's possible that my diagnosis of the exact problem is wrong, and that it's not the symlink
but something else which offends SELinux.  All I can say is that /var/lib/pgsql/base being a
directory owned by the postgres user works perfectly, but /var/lib/pgsql/base being a symlink
to a directory owned by the postgres user on another filesystem does not.  Postgres can be
started after a "setenforce 0" so it's certain that SELinux is the problem.  I honestly have
no idea where this particular SELinux policy originates, or is expressed.  But I do know that
it seems to have been known to postgres developers since at least 2005.

http://archives.postgresql.org/pgsql-admin/2005-09/msg003...

The same topic, from 2006, on the Fedora list:

http://linux.derkeiler.com/Mailing-Lists/Fedora/2006-05/m...

SELinux and Fedora

Posted Jul 10, 2008 17:46 UTC (Thu) by dpquigl (guest, #52852) [Link] (4 responses)

I'll do my best to try and explain the problem here. For future reference a quick email to the
fedora-selinux, or NSA SELinux mailing lists will probably save you a lot of time and headache
and usually gets a quick reply.

The issue here is that a symlink is not the same as a directory. In the Linux DAC model
everything is treated the same. A file/directory/symlink etc.. all only have permissions based
on the traditional Unix permission bits. So there is no different between the file and a
symlink to the file because in the end the symlink will just resolve to that file anyway. In
SELinux we make a distinction between the many types of objects in the system. Files,
Directories, Sockets, Pipes, Symlinks, etc all are different and while some may share
permissions they aren't the same permission. So let's consider what happened in your case. The
policy says that postgres has the ability to look in a directory labeled a certain way and
read files labeled a certain way. All of a sudden what the program once thought was a
directory is now a symlink. Normally this isn't an issue because it will be resolved, however
chances are the link does not have the proper label and the policy isn't allowed to follow
symlinks of that type. For this reason SELinux blocks the access. You can probably imagine
several ways that symlinks can be used to trick postgres into doing something that wasn't
intended so this is a resonable security precaution.

There are two solutions to this problem.

1) Label the symlink correctly and if postgres isn't allowed to follow symlinks of that type
create a loadable policy module to allow it. This is a little more advanced for a regular user
and might be more than they are willing to do.

2) Bind mount the directory. Since bind mounts are just namespace manipulation even though the
directory is pointing somewhere else it is still a directory and it is still labeled with the
appropriate label. This is a much better solution since it won't require any policy
modifications.

In either of these steps it helps to add an entry using semanage for file_contexts to say that
the files under your new location keep a certain label on relabeling. This is normally taken
care of for you if everything is in the default location but since you have moved it if you
perform a system relabel it could steamroll your labels.

Hopefully this explained what was going on and will help you when you want to move things into
non-standard directories in the future. This and a bunch more information will eventually make
its way to selinuxproject.org

SELinux and Fedora

Posted Jul 10, 2008 18:22 UTC (Thu) by jwb (guest, #15467) [Link] (3 responses)

I think I speak for the average Linux user when I say:

What are you talking about?

Label?  Context?  These are not Unix concepts.  SELinux has secretly replaced my Unix system
with Folger's Crystals.  Let's see if anyone notices.

You say "You can probably imagine several ways that symlinks can be used to trick postgres
into doing something that wasn't intended."  Actually, I cannot think of any such thing.  Can
you perhaps explain to me how an adversarial symlink would have magically appeared in
/var/lib/pgsql under the traditional Unix security model?  Keep in mind that this directory is
owned drwx------ postgres postgres.

The question posed in the article was whether SELinux should be enabled by default.  If your
comment is any indication, SELinux is from another galaxy, and definitely should not be
enabled by default for people who were under the impression that they were using Linux.  If
there are customers who are insisting on this foreign access control system, then they are
probably smart enough to turn it on.

SELinux and Fedora

Posted Jul 10, 2008 19:36 UTC (Thu) by dpquigl (guest, #52852) [Link] (1 responses)

I think your statement is a little off. Also if you are a Linux sys admin with 10 years of
experience you aren't the average desktop user which is probably not doing what you are trying
to do.

These ideas have been in trusted Unixes for quite some time I think it is better to phrase
your statement as these aren't DAC concepts and I completely agree with you. You are thinking
of these things in terms of people who own it. MAC separates itself from DAC by saying we can
take all potential security relevant information into account when making a decision.

In the Unix DAC model you say this person owns this file. This group owns this file and this
is how this person and this group can interact with it. Even with ACLS it is the same but you
get more than user and group. MAC at least how it is implemented with SELinux says something
completely different. It says users aren't the ones performing actions because you aren't but
rather you invoke programs which perform actions.

An example of this is passwd. Since it access a privileged resource /etc/passwd it is marked
as a setuid application and is owned by root. The better thing to say here is what programs
should have access to that file and the answer is clear. passwd should have access to it and
programs that need to authenticate user credentials. Even then they should only be able to
read from it most of the time. This way if I have a compromised daemon running as root there
is no way for it to get access to my password file. This is because I didn't say that it is
root and can read everything root can but rather program foo has no right to read the password
file and send it somewhere.

So you are still thinking about this in terms of people ownership. In SELinux every process
and every object in the system are given a security context. A security context is the
security information associated with the object. In the case of SELinux there are several
parts to it but the most important is the type. This is what is mainly used to confine
applications and describe their behavior. The problem with DAC is an all or nothing mentality.

I am Dave. I am performing an action as Dave. My program does something malicious that I
didn't think it would do and has corrupted some files owned by Dave. The problem here is
everything was authenticated using Dave. The program which had no right touching certain
files which I didn't ask it to was able to corrupt them because they were owned by Dave so the
program could do whatever it wanted to any file as long as I owned it.

So back to SELinux now. There is no direct equivalent of this person owns this file. The
equivalent problem here in DAC is this. I've created a file I want a program to use. It is
owned by the complete wrong user. What is the solution? chown the file to the right user. In
SELinux terms this is I've created this file. I need this program to be able to access it.
However it has the wrong type what do I do? chcon the file to the appropriate type. Now you
can ask what is the appropriate type and that takes a bit of digging but it's possible to find
out.

To address your second paragraph upon looking at it this seems like a case of the policy being
a bit overly strict. In reality if you are able to read the contents of the directory that the
symlink is in and it inherits its security information from its parent you should probably be
able to follow it. But by no means should postgres be able to create that symlink.

To address your last paragraph I would not say it is from another galaxy. It is just a little
different. It may take a little bit of getting use to but it is immensely more powerful in
securing a system than DAC is. It just takes some time and a good book to understand. If you
want to take the time to learn SELinux (which is completely up to you) then I'd really suggest
reading Dan Walsh's blog and after briefly looking over the link posted in a latter comment
I'd say to look at that website as well. Both contain a lot of information about SELinux, how
it works, and what it accomplishes.

SELinux and Fedora

Posted Jul 11, 2008 10:49 UTC (Fri) by macc (guest, #510) [Link]

It does not KISS.

SE Linux introduces dependency on some person 
living inside SE Linux.

And it is not simple powerfullness as the 
original unix concept provides.

SE Linux is like german. You can build 
brilliantly convoluted sentences using 
a plethora of multisylable words but you 
are always in danger of loosing contact
to the tale you wanted to tell about.

SE Linux is not comparable to taking out
the airbags but more like the seat+belt-contacts
that prohibited starting the engine if 
a seated person was not secured by a seatbelt.

not good.

G!
MACC

SELinux and Fedora

Posted Jul 10, 2008 21:50 UTC (Thu) by Tet (subscriber, #5433) [Link]

Label? Context? These are not Unix concepts.

They are now. It's true that they weren't present in V7 Unix. But then again, neither were many of the other concepts we find in a modern day Unix. That's the nature of progress. Things change. It took me a long time before I was sold on SELinux, and my gut instinct was to turn it off, and run my machine with traditional Unix permissions. But just as I wouldn't dream of running a machine without a firewall in 2008, I now wouldn't dream of running one without SELinux. The landscape has changed, and Linux (and indeed, OSes in general) need to adapt. The benefits of running SELinux outweigh the initial pain it caused, and I believe Red Hat are 100% correct to have it turned on by default.

SELinux and Fedora

Posted Jul 10, 2008 17:31 UTC (Thu) by smoogen (subscriber, #97) [Link]

selinux only disables symlinks if you are trying to go between security contexts. as in having
a symlink in /tmp pointing to /etc/passwd so you can replace its contents with webapp x.
[Which is why I now make sure selinux is turned on my sql and webservers as the ones that
didn't have it on got busted.]

So normally you need to make sure that what you are pointing to has the correct context so
that the program you want will work.

SELinux conceptual complexity

Posted Jul 10, 2008 4:24 UTC (Thu) by anchorsystems (guest, #40101) [Link] (13 responses)

It seem that the biggest problem with SELinux is that
it has been designed from the most complex conceptual
model, as required to represent most classical security
models, rather than just starting with the simplest model
required to add basic MAC.

And this complexity makes every other aspect of it a
nightmare to work with.

I'm guessing that most people and policies don't make
use of the user, role, sensitivity, or categorisation.

Having all those aspects hidden and disabled when not
used to allow SIMPLE policies that rely on just
type/domain and transition rules would help understanding
immensely.

Not really

Posted Jul 10, 2008 6:53 UTC (Thu) by khim (subscriber, #9252) [Link] (12 responses)

Take a look on frustrated user just above. Biggest problem with SELinux was not the fact that it's complex but simply the fact that it works differently then plain Linux.

I could not get postgres to start, even though I've installed it that way dozens of times is THE ONLY real problem with SELinux - but any security solution which will allow you to do things in exact same way you did it "dozen of times" is totally, utterly USELESS. Because security solutions are designed to stop attacker and till we'll have reliable telepathy-based function is_Attacker(3) security solutions will hurt admins from time to time - or will not hurt attackers at all...

Not really

Posted Jul 10, 2008 7:19 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Well, yes, but when it hurts normal admins it has *failed*: that's a false 
positive, because it's blocking someone who is *not* an attacker.

Not really

Posted Jul 10, 2008 7:34 UTC (Thu) by edomaur (subscriber, #14520) [Link]

What I think is utterly useless, is the way error messages are written. The "access denied"
message doesn't give enough information to really help. Generally speaking, I do not work with
SELinux because it is too much work to do the easy part of securing a server. But when I have
no choice and _must_ use SELinux, one of the first thing I do is tagging its error messages
with a nice "[SELINUX]" sticker. Much headache can be avoided...

There is also the problem of the complexity of SELinux : ok, this is a very good security
framework, but it is too hard to explain and to use to/by a casual sysadmin (which is somewhat
common). If someone doesn't want to be bothered with learning the intricacies of SELinux, he
will just disable the policies, or switch to a distro without SELinux enabled by default.

Not really

Posted Jul 10, 2008 10:16 UTC (Thu) by lysse (guest, #3190) [Link]

Heh - can't help thinking of the state of American airports here... perhaps there are a couple too many "security-first" people who would class such high visibility as a success? ;)

Not really

Posted Jul 10, 2008 8:50 UTC (Thu) by jschrod (subscriber, #1646) [Link] (8 responses)

No, the problem of that PostgreSQL denial was not that the admin was unfamiliar with SELINUX and that it doesn't work different than on plain Linux.

The problem is actually many-fold, and can be nicely illustrated by the example that you cited:

SELINUX forbids to use standard installation schemes. (Here: symlinking the location of a database to a different filesystem while keeping ownerships.) The security-related related disadvantage of that standard installation scheme is not obvious and there is no explanation delivered to the sysadmin why it is done that way and how to mitigate that problem / realize that standard installation scheme with SELINUX.
The error message that are caused by SELINUX are worthless to identify the root cause of the problem. AFAIK, this is a configuration problem, but configuration problems are real problems, too.
SELINUX documentation is often uncomprehensible for experiences Unix sysadmins with many decades of working experience, even if they try hard. IMNSHO, this is not a problem of the sysadmins, this is a problem of SELINUX.
SELINUX proponents don't accept SELINUX's share of blame, but blame the user instead and imply that he isn't willing to adapt to new ways. And that even if the user tells them that he spent hours or even days trying to work out the new way. In fact, they tell their users that they are dumb. Guess what? Users don't like being (implicitly) called dumb. These proponents don't even seem to see that they alienate potential users with that behaviour and are actually one of the biggest dangers for SELINUX uptake.

Well, my 0.02 EUR on that topic.

Not really

Posted Jul 10, 2008 13:39 UTC (Thu) by kh (guest, #19413) [Link] (1 responses)

I have been thinking that the traditional Unix security model has strength because of its
simplicity:

1) It is easy for any normal sysadmin to understand

2) It is easy to audit

3) It is easy to edit 

Maybe there is a wealth of tools and custom scripts out there for selinux that I am not aware
of, but I do not think they exist because selinux is too difficult to completely
conceptualize.

I also do not understand why any type of selinux (or any other security) error should be
anything other than noisy and verbose, especially when installed by default on a desktop. Does
selinux give silently logged errors that should be ignored by an average user?

Not really

Posted Jul 10, 2008 14:20 UTC (Thu) by jschrod (subscriber, #1646) [Link]

I agree with you mostly.

Concerning the error messages, in my experience, it is even worse: Not only are they not
sensible for an average desktop user, they are not even sensible for an experienced sysadmin
user! Therefore, using SELINUX on a desktop system is doomed to cause great pains for the user
community. (It bothers me only on an abstract level, though. On the desktop, I use SUSE...
:-))

But I don't think that the traditional Unix security model (easy as it is) can survive in the
long run. In our Internet-connected age the environment and associated threat model got more
complex, and such simple solutions won't be adequate in the long run. But I don't have any
idea how one can teach compartimentation and MAC to run-of-the-mill sysadmins and end-users
who are forced to be their own sysadmins.

Not really

Posted Jul 10, 2008 18:03 UTC (Thu) by dpquigl (guest, #52852) [Link] (4 responses)

2) I would like to have seen the error that he was getting from postgres but I have a feeling
if you ran it through one of the several tools it would have become apparent that postgres
didn't have permission to follow symlinks. However, this stems from needing to know that there
is a difference between symlinks and directories so even if it was clear in the message it
would need further explanation.

3) I agree that SELinux documentation is lacking at the moment but there are several efforts
currently going on to work on this. I have been preparing a series of tutorials and
presentations for educating people about the security model SELinux implements and how to
configure a machine in non-standard ways such that it still works with SELinux. Also there is
now someone working full time to generate documentation for SELinux.

4) We have seen this complains come up quite a few times and we can't figure out where it
comes from. Have you had personal experience with someone in the community treating you this
way? When I first started learning about SELinux I had many questions and the community was
very helpful and didn't make me feel stupid for asking them. If you have specific examples of
this I'd be glad to see them. It is possible that this might be a residual complaint from the
early days of SELinux that has hung around like some of the other complaints people have about
SELinux.

Not really

Posted Jul 10, 2008 18:12 UTC (Thu) by dpquigl (guest, #52852) [Link]

I forgot to mention, if there is anything you would like to see in the SELinux documentation
feel free to send suggestions to the mailing list and we will see about integrating them into
the documentation list.

Not really

Posted Jul 15, 2008 8:24 UTC (Tue) by mauvaisours (guest, #6130) [Link] (2 responses)

I've been hurt by SELinux some years ago, when installing a server that I needed for a quick
demo. At that time, I was only semi-aware that RH had turned SELinux on by default. So when
things got wrong (from my point of view), I was completely baffled. 

The big black point of SELinux is that it does not show up in standard commands [ls, ...], so
that the message you get is "permission denied", but you have no way of knowing why. 

And the documentation was (is?) so thin on the subject that all I could do (at the time) was
just shut it down, and as I was too busy, I never looked at it again, and I disable it on all
new installs.

So my guess would be : 
1/ Write an extensive documentation
2/ Make people read that doc (it's not that hard. I would.)
3/ Include that documentation on standard distros.
4/ Turn SELinux on by default.

It was done in the wrong order.

Not really

Posted Jul 15, 2008 18:44 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Hah, I wish. It is *very* hard to get most people to read any 
documentation at all, generally because they don't care about SELinux (or 
any security system protecting against *potential* threats) until it 
causes problems, by which point things have already gone wrong. (If 
they're not running it they may suddenly start caring when they get 
rooted, but that, again, is too late.)

Nobody knows how to resolve this particular dilemma :(

Not really

Posted Jul 15, 2008 19:38 UTC (Tue) by mauvaisours (guest, #6130) [Link]

I agree that nobody knows how to resolve this dilemna, but pushing a new undocumented security
model to users is certainly not the way to go.

Re: Not really

Posted Jul 11, 2008 16:03 UTC (Fri) by jmmc (guest, #34939) [Link]

Also wanted to back up  dpquigl  in response to your #4 point...

At absolutely NO point have I ever encountered a response about SELinux from anyone (lists,
irc, etc) who was condescending to me or considered my inquires 'simple' or 'stupid'. I think
this comment is overly harsh in that regard.

Heck, I've learned quite a bit just in the 50+ or so comments here today - thanks again to OFE
(Our Favorite Editor, JC for even keeping this topic important, which it is, imho).

Lastly, I support SELinux 'policy ON by default'. Kudos to RedHat for being persistent on this
matter. I was trained that good policy on *NIX was always 'deny by default, allow by approved
request' from well before the SEL era...and default SEL is violating that principle ?...how ?

SELinux and Fedora

Posted Jul 10, 2008 7:38 UTC (Thu) by Mog (subscriber, #29529) [Link] (3 responses)

When I setup a new computer, the very first thing I do after install is
to set sshd to listen to a port other than 22.
I googled a lot, read a lot of docs, and I still haven't found how to do
this with SELinux, except with SELINUX=disabled.
I have a 20y Unix experience, I am always willing to learn new stuff, but
this is madness.

SELinux and Fedora

Posted Jul 10, 2008 8:38 UTC (Thu) by evgeny (subscriber, #774) [Link]

There is an advice: http://equivocation.org/node/124

SELinux and Fedora

Posted Jul 10, 2008 8:49 UTC (Thu) by k3ninho (subscriber, #50375) [Link] (1 responses)

I haven't tried the example set out at equivocation.org, but does http://equivocation.org/node/124 appply to you and solve the problem?

K3n.

SELinux and Fedora

Posted Jul 10, 2008 17:26 UTC (Thu) by dpquigl (guest, #52852) [Link]

The example will work and there is another example on Dan Walsh's blog about configuring httpd
to run on ports other than 80 which explains the core issue.

Let's explain exactly what is going wrong here. In SELinux the application's behavior is
described with a set of rules. SELinux goes beyond the everything is a file mentality and it
also labels other objects such as pipes, directories, symlinks, and sockets. This means that
each socket has a label. The policy for sshd says sockets that sshd is going to use are
labeled ssh_port_t. If you want a list of the ports and how they are labeled you can type
/usr/sbin/semanage port -l . This will show you all of the ports that are labeled and what
they are labeled with. So let's say you moved the port for mysql. You can check what type
mysql uses by typing /usr/sbin/semanage port -l | grep mysql . You will get the line below on
a standard f9 box.

mysqld_port_t tcp 1186, 3306, 63132-63136

You can usually use this method to find out the type for any confined network daemon. Now
let's say we changed mysqld to be on port 1187 instead of 1186. The problem here is that the
policy says that mysqld can only talk on ports labeled mysqld_port_t. If a port isn't in this
list is labeled in two ways by default reserved_t for < 1024 and unlabeled_t for > 1024 so
what happens here is mysqld would try to type to a port that is labeled unlabeled_t which it
can't do. To fix this we have to say that 1187 is labeled as mysqld_port_t which is easy to do
using the semanage command.

/usr/sbin/semanage port -a -p tcp -t mysqld_port_t 1187

You can use this method for any confined application. The idea to take from this is an
application can only talk on ports labeled with a type it has access to. To make it use a
non-standard port you have to apply the right label to the port. You can usually find it by
looking through the output of semanage port -l and once you find it you can easily add it with
semanage port -a -p <proto> -t <type> port

I hope you found this useful. Eventually this information with a bunch of other SELinux
tutorial materials will make its way to selinuxproject.org

SELinux and Fedora

Posted Jul 10, 2008 8:45 UTC (Thu) by yodermk (subscriber, #3803) [Link] (3 responses)

> When that happens, SELinux can be put into permissive mode with a simple GUI or
configuration file change, followed by a reboot.

Wrong -- a reboot is NOT required to put it into permissive mode.  Just run:

# setenforce 0

(I suspect there's a GUI equivalent) and it takes effect immediately, even for processes
already running.

A reboot IS required to disable it completely, but if you do that, to enable it again requires
re-labeling your whole filesystem.

SELinux and Fedora

Posted Jul 11, 2008 2:14 UTC (Fri) by mgb (guest, #3226) [Link] (2 responses)

This may be a dumb question, but what's to stop the putative black hat from issuing
"setenforce 0" before merrily working his evil?

SELinux and Fedora

Posted Jul 11, 2008 7:48 UTC (Fri) by petebull (subscriber, #7857) [Link] (1 responses)

My guess: that command is not available for over the net access, it's only 
executable at the console.

SELinux and Fedora

Posted Jul 11, 2008 18:51 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, yeah, but part of the point of SELinux was, I thought, that root 
could be confined. (Not that this is terribly useful, because there are 
too many ways that root can mess up the machine. To hear PaXTeam et al 
talk, everyone's running with a confined root so that DoS attacks and 
holes only exploitable by root are significant. I find it rather unlikely 
that *anyone* who cares about security is running under the assumption 
that confined root really is secure, exactly because of the enormous 
number of such 'attacks'. But I don't have any numbers and may be wrong.)

SELinux and Fedora

Posted Jul 10, 2008 8:54 UTC (Thu) by mjthayer (guest, #39183) [Link]

I think that one of the problems of SELinux is that it tries to add security to Linux-based
systems _tranparently_.  Existing software should not need to be modified (at least not in any
significant way), and should ideally not even have to know that SELinux is there.  And that is
to my mind why it is so hard to work out what is going wrong when something does go wrong -
the software giving out error messages is not aware of the source of the "problem".

Change is good when it brings worthy improvements, like security

Posted Jul 10, 2008 9:46 UTC (Thu) by rvfh (guest, #31018) [Link] (4 responses)

Everything I read (article and comments) reminds me of a previous job where everybody had the
root password of our build server (I was the admin).

Once, someone typed reboot as root on the server instead of his target (both remote access),
and I took this opportunity to change the root password and not give it away, except to a
deputy and a manager (for obvious reasons).

Most colleagues didn't mind, but one was extremely worried of seeing some of his 'rights' go
away, and I told him that I would give him sudo access for anything he needed to do and could
not do as a normal user.

In the end, he never came asking for anything, because nothing he did required high
privileges, and I think it's a bit the same here. It's some kind of FUD.

Also, interestingly, people who report most issues seem to start by saying 'I worked with
Linux for the last two centuries blah blah blah...'  Yes, but this is changing things, so
indeed it brings new problems, and new solutions, and it does not matter that you are an
expert in this or that, you may also have to learn the basics of SELinux, just like you has to
learn the basics of VI, Bash, [add your own little admin tool here]

Change is good when it brings worthy improvements, like security

Posted Jul 10, 2008 20:04 UTC (Thu) by mrshiny (guest, #4266) [Link] (3 responses)

Amen: a new system requires new knowledge, and that's why SELinux isn't gaining user
acceptance.  That, and the fact that it's hard to use, so even admins can struggle with it.

Normal LS doesn't show the context of a file
It can be tricky to set up new labelling rules
Until recently it was really annoying to diagnose what was failing and why

Fedora 8 fixed this for me with the SEAlert applet.  Now when there is an SELinux failure on
my system I can see what is wrong, and what command I should run to allow the access that was
denied.  This helps a great deal.  What we need now is a tool which lets you, for a specific
program, generate new SELinux rules so that you can install something and have it just work.
For example, I like to run my HTTP doc-root in /home/httpd (I'm a hold-out from RH 6).  SELinux
makes this nearlly impossible.  I've given up on this and resorted to manually changing the
labels of files.  But given how arcane this is I can see why people still resist.

Change is good when it brings worthy improvements, like security

Posted Jul 15, 2008 22:09 UTC (Tue) by dpquigl (guest, #52852) [Link] (2 responses)

/usr/sbin/semanage fcontext -a -t httpd_sys_content_t '/home/httpd(/.*)?'
restorecon -R -v /home/httpd

That should fix your problem.

The first line tells the policy that all files under /home/httpd and the directory itself
should be labeled with httpd_sys_content_t. This will allow httpd access to it. The second
then relabels all of the files under that point so they are correct. Something to take note
of. If there is more explicit labeling rule on a file for instance /home/httpd/foo the above
line won't override it. So if you have a cgi directory under that point you can do something
along the lines of 

/usr/sbin/semanage fcontext -a -t httpd_sys_script_exec_t '/home/httpd/cgi/*'  it will label
everything under that with httpd_sys_script_exec_t and everything else will match the first
rule above. I might be wrong with the syntax on the regex but you get the idea. The more
explicit the path the more authoritative it is.

If you have any more problems feel free to email the fedora-selinux list and I'm sure you will
get a quick answer to your question and a solution to whatever problem you are having.

Change is good when it brings worthy improvements, like security

Posted Jul 15, 2008 22:15 UTC (Tue) by dpquigl (guest, #52852) [Link] (1 responses)

I also found on Dan Walsh's blog that there is a GUI for doing this as well.

"You can see similar functionality in system-config-selinux by selecting the 'File Labeling'
list item and then clicking on the 'Customized' button."

Change is good when it brings worthy improvements, like security

Posted Jul 17, 2008 3:45 UTC (Thu) by mrshiny (guest, #4266) [Link]

Thanks for the tip.  I had already gone down this road with the gui tool and found that
something didn't work properly and my attempts at manually setting this stuff failed.  I
eventually gave up and moved my doc root or just manually changed the context... I forget.  I
think I manually changed the context and I expect it to fail if the whole system gets
re-labelled.

It would be much easier for a sysadmin to be able to specify the document root in the apache
config file and have an selinux-aware tool say "gee, looks like you'll need to add these
se-linux rules... proceed? Y/N".  But at least much progress has been made with these tools
compared to Fedora 2.

The imitation angle

Posted Jul 10, 2008 12:25 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link] (2 responses)

If the ideas expressed in SELinux add so much value then why have these ideas not gained
traction with TdR and the OpenBSD crowd, who tout themselves as the last word in recreational
paranoia?
This is a serious question, not intended as a troll or endorsement or anything.
Lack of imitators may mean something.  Or not.

The imitation angle

Posted Jul 10, 2008 15:03 UTC (Thu) by scripter (subscriber, #2654) [Link]

Google for "selinux bsd". I came up with the following, among other things: http://www.trustedbsd.org/sebsd.html

The imitation angle

Posted Jul 10, 2008 16:53 UTC (Thu) by dpquigl (guest, #52852) [Link]

SEDarwin (MAC OS X)
http://www.sedarwin.org/

SEBSD
http://www.trustedbsd.org/sebsd.html

FMAC (Open Solaris with Flask integration)
http://opensolaris.org/os/project/fmac/

Xen Security Modules & Flask Module (Note XSM is already in Xen)
http://xen.xensource.com/files/xensummit_4/xsm-summit-041...

XACE & Flask/TE Support for X (Note XACE is already merged into the mainline xorg tree with
the flask module)
http://people.freedesktop.org/~ewalsh/xace_proposal.html

SELinux and Fedora

Posted Jul 10, 2008 13:16 UTC (Thu) by russell (guest, #10458) [Link] (3 responses)

This is just more of the trend in Fedora to tell users how to use there system.

With F9 we have a gdm missing lots of features and a missing gdmsetup, 

NetworkManager that only provides a wireless connection if someone is logged in ( who needs
NTP/sshd/etc anyway ).

SElinux without without easy control of the policy or obvious off switch.  Yes, some of us
would rather take the risk than deal with the bugs.

And some really really annoying thing that randomly checks my screen brightness and sets it to
50%.

The frustration is feeling more and more like Windows everyday. Where did the freedom go.

SELinux and Fedora

Posted Jul 10, 2008 15:26 UTC (Thu) by drfickle (guest, #1093) [Link] (2 responses)

> With F9 we have a gdm missing lots of features and a missing gdmsetup, 

I think that's the fault of upstream GNOME, and not Fedora-specific.

> And some really really annoying thing that randomly checks my screen 
> brightness and sets it to 50%.

I believe the GNOME Power Manager tool can fix this by changing your 'battery mode' settings.
From what I've seen, most people are willing to trade brightness for battery life.

> Where did the freedom go.

You're free to use any other OS and/or distribution :) You're also free to change the code.
Even if you're not a coder, you're free to join the Fedora mailing lists and argue against
these kind of choices. That's a lot of freedom!

SELinux and Fedora

Posted Jul 10, 2008 22:36 UTC (Thu) by Frej (guest, #4165) [Link]

> I think that's the fault of upstream GNOME, and not Fedora-specific.

No, upstream GNOME (release team), decided that the new gdm wasn't ready for 2.22. So it's
fedora specific. Hopefully the missing features will be fixed for 2.24.

SELinux and Fedora

Posted Jul 11, 2008 0:17 UTC (Fri) by russell (guest, #10458) [Link]

I was using the laptop in bed, trying not to wake my wife up, so I had the brightness right
down.  It was turning it up to 50%.   Needless to say, I wasn't using the laptop for very
long.

SELinux and Fedora

Posted Jul 10, 2008 13:36 UTC (Thu) by gdt (subscriber, #6284) [Link] (1 responses)

I've followed SELinux from its earliest days. It has moved from a nightmare to a nice product which pops up windows whenever it block access. This is far superior to the Windows Vista approach of putting up a dialog box beforehand saying "allow me to malware your computer (y/n)?". In fact the nice GUI interfaces to SELinux make it much less of a hassle to run on a desktop than on a text-mode server.

As for the need for SELinux, it's the only technology I've seen that puts me well ahead of the "race to patch" in maintaining system security.

If I were to make a criticism of SELinux under Fedora it would be "where's the benefit for the desktop user"? There's obviously benefit for servers -- where processes are essentially sandboxed in the data they can access. But the rules for desktops are deficient. As a trivial example why can I execute files from ~/Pictures/* -- aren't all of those files meant to be images? Why can The Gimp read files from ~/bin -- aren't all those files meant to be executables?

Sure these sort of policies mean that users need to follow a centralised dictat of what goes where, but such a dictat is also the thing which prevents a subverted Firefox from reading and writing the files in ~/Documents (and thus having malware encrypt my documents and hold them hostage).

SELinux and Fedora

Posted Jul 10, 2008 18:38 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]


http://fedoraproject.org/wiki/SELinux/FAQ has more details on where it benefits desktop users.
Specifically important desktop software with a long history of being prone to vulnerabilities
such as a web browser is covered by SELinux policy in Fedora.

SELinux and upstream developers

Posted Jul 10, 2008 15:59 UTC (Thu) by jch (guest, #51929) [Link] (4 responses)

One thing that I cannot understand is why the SELinux crowd are not trying to get the upstream
authors to write security policies for their software.  Aren't the authors the only people who
understand the software well enough to write a suitable policy that works in all cases?

SELinux and upstream developers

Posted Jul 10, 2008 17:10 UTC (Thu) by dpquigl (guest, #52852) [Link] (2 responses)

This is a very good point and I agree that upstream developers should be involved in policy
writing but there are several issues with this.

1) A developer is usually working on new features and bug fixes and that is their main focus.
While it would be great if every project had someone like Dan Walsh or Chris PeBenito who
would just work on the SELinux policy for their project this is not the case.

2) Not everyone runs systems with SELinux integration. Right now the main distro for SELinux
integration and development is Fedore. If you want SELinux in Gentoo you need to use hardened.
Debian was one of the first distros to integrate SELinux and it works well but they are still
using a split strict/targeted policy. Ubuntu now has SELinux support integrated but they are
going in a different direction with respect to policy.

3) The upstream policy maintainers and Tresys provide what is called a reference policy which
everyone can use as a start. However each distro may patch the policy how they see necessary
for their particular needs. The Red Hat policy makes a lot of changes to the upstream policy.
This could potentially make policy development difficult.

That being said this is still a good idea and hopefully it can happen soon. The best start for
this would be to break each of the applications policies out into their own packages that ship
with the main application package. Recent developments in the toolchain have made this more of
a possibility. The issue now is to get people in each project that understand SELinux and how
to write policy for it.

SELinux and upstream developers

Posted Jul 12, 2008 23:12 UTC (Sat) by jch (guest, #51929) [Link] (1 responses)

> 1) A developer is usually working on new features and bug fixes and that is their main
focus.

While I'm grateful to learn what a developer is usually working on, a great many of us do
spend a significant amount of time ensuring that our software is secure.  Any tools to help
would be welcome.

SELinux and upstream developers

Posted Jul 15, 2008 16:50 UTC (Tue) by dpquigl (guest, #52852) [Link]

Perhaps my wording was off. I didn't mean to imply that developers don't care about writing
secure software or that security isn't in mind when developing but rather that if it comes
down to implementing feature X or writing SELinux policy chances are feature X is going to be
implemented first. Unless you have someone who's job it is to keep track of what is changing
in your project and update your SELinux policy accordingly, your policy will be an
afterthought. I'd be glad to be proved wrong on this but sadly based on what I've seen this
seems to be the case.

SELinux and upstream developers

Posted Jul 10, 2008 17:37 UTC (Thu) by smoogen (subscriber, #97) [Link]

Actually the Selinux people do try to get the upstream people to write policies for their
software. Not everyone wants to do that (I just found where an ISV consultant turned various
core programs setuid because the Unix security model was getting around their program.)

SELinux and Fedora

Posted Jul 10, 2008 20:11 UTC (Thu) by sgros (guest, #36440) [Link] (2 responses)

It's interesting to see how many people claim they are long time pro Unix admins and they
can't understand SELinux. What's worse, I get impression that they don't want to learn it. For
comparison, I'm aware of sysadmins that don't want LDAP because they don't understand it and
stick either with text files or at best with some SQL database.

Personally, I believe that SELinux is not the first, and certainly not the last frustration
for a _good_ sysadmin. Each new technology requires a period of learning, and that's
especially true with security technologies who sole purpose is to _restrict_ users!
Furthermore, as already one poster noted, Unix was simple, but it was when everything was
simpler and there was no Internet and so much attackers, malware and stupid users!

Not to say that SELinux is simple, but, it's not a rocket science either...

SELinux and Fedora

Posted Jul 11, 2008 0:34 UTC (Fri) by russell (guest, #10458) [Link]

Regardless of how good it is. It won't be effective unless people can use it.  Technically I'm
sure it's wonderful but the current situation with SELinux is that it's too complicated for
most people ( even good sysadmins ).  It will probably always be too complicated, it was
designed that way and that's a design floor not easily fixed.

To me it looks like the anti-virus software you see on other platforms.  It's a black box you
don't understand but are told you need.  It's reactive security, rather than fix the
underlying problem, just fence it off.  You are dependant on an external company for security
updates.  If it messes with something you need to do, the only option (sometimes) is to
disable it.

SELinux and Fedora

Posted Jul 12, 2008 14:10 UTC (Sat) by kleptog (guest, #1183) [Link]

I've found SELinux an interesting but somehow never worked out how it works. Most of my
experience is unexplained permission denied errors. In the comments there is mention of a
program that will tell you when something was denied by SELinux, which is a huge step forward.
I have got as far as labels being strings and files and processes have them, but how exactly
that leads to the controlling of permissions (the magic ingredient) still eludes me.

From recollection I don't think LWN has ever done an SELinux primer, for example.

I've found an 'SELinux for Dummies' and am quite a few articles in, but the magic ingredient
has not yet been revealed... At this point I'm guessing a database of some sort. I'm hoping at
some point some pseudocode will appear that describes exactly how it works.

SELinux and Fedora

Posted Jul 11, 2008 14:52 UTC (Fri) by yyidth (guest, #18842) [Link] (3 responses)

Honestly, please stop writing articles like this. Why is LWN acting as an apologist for a
failed security infrastructure? The kernel team has all but kicked them out with the opening
of the LSM api and inclusion of SMACK in the source tree. In 5 years those of us who are
professional Unix admins will look back at SELinux with annoyance and be glad it's gone. One
or another of the current crop of tools with equivalent functionality, a usable configuration
methodology and complete documentation will have replaced it across the board.

I have a great deal of respect for both the work and to workers that is SELinux. It was
basically the first, but as is often the case with a first attempt at a new tech the
implementation falls off the mark. In the case of SELinux a mistake was made in moving to far
away form standard Unix behavior and a config system that seems to try its best to be obtuse.
On top of the complete lack of documentation and the complete uselessness of the log messages
SELinux ends of being unusable by a busy professional admin.

And so, until Fedora, Redhat, Ubuntu and the like move forward problems with SELinux are best
dealt with using the directive SELINUX=disabled in /etc/selinux/config.

SELinux and Fedora

Posted Jul 11, 2008 18:55 UTC (Fri) by nix (subscriber, #2304) [Link]

I'm not much of an SELinux fan, but your claim that 'the kernel team has 
all but kicked [the SELinux developers? SELinux itself?] out with the 
opening of the LSM api' is ludicrous. Providing extra choices doesn't mean 
that the existing choices are anathematized!

SELinux and Fedora

Posted Jul 11, 2008 20:36 UTC (Fri) by luya (subscriber, #50741) [Link]

To be analogical, it looks like someon is turning off ABS and traction control.

SELinux and Fedora

Posted Jul 11, 2008 21:34 UTC (Fri) by Los__D (guest, #15263) [Link]

Honestly, please STFU, and stop telling LWN what to cover.

SELinux and Fedora

Posted Jul 14, 2008 0:40 UTC (Mon) by mmarlowe (guest, #11374) [Link]

Count me in as another experienced sysadmin who isn't sold on SE Linux.  Yes, I've been using
it here and there and attempting to get better at troubleshooting issues with it....but mostly
I'm holding off production deployments until the technology matures further.

The following issues are some of what bothers me:

a) SELinux still seems too much of a black box ....I have had situations where working
applications running under selinux start having issues months after deployment and after I
assumed all critical problems had been debugged (I think it comes down to the fact that
selinux requires the admin to be much much more precise on defining the behavior of
applications, but the admin doesn't always know how those behaviors are going to change over
time).

b) We had some servers crash recently because selinux was silently logging access errors for a
very busy webserver and storing the messeges in ram apparently or there was a memory leak in
setroubleshoot.  System went through 4GB of ram for selinux purposes within an hour of
boot...shutting off selinux eventually allowed the system to stay in operation until our
developers realized that a recent change in their application was violating policies.

c) As an Admin, I like to setup machines and be generally aware of what developers are up to
(to the extent it impacts system reliability, performance, and security) but I dont want to
know every last detail of their new apps...and selinux somewhat forces me to be much more
involved so that I know all the directories they are accessing for each app/etc as well as
network ports I might not have needed to know about before.  

d) And lastly, I'm still working out how to get the whole logging mechanism for selinux
working properly.  I don't want any applets involved on the server, and all our syslog
messeges go to a central splunk server which is configured for various live reports and
alerting.  You'd think there'd be an easy way to get alerted on the appropriate selinux
messeges but there doesn't appear to be, especially as we have to carefully tune what messeges
are "normal" and which really require attention.

So, as much as I agree with the principles of se linux and want it to be deployed eventually
in all production environments, I am somewhat frustrated at RedHat forcing it's customer base
to be beta testers of what essentially isn't production ready software.

Hopefully, the concerns will go away by a RHEL7 release.

SELinux and Fedora

Posted Jul 14, 2008 17:38 UTC (Mon) by pjones (subscriber, #31722) [Link] (2 responses)

Not only is SELinux enabled, but the installer no longer has an option to disable it or to put it into "permissive" mode.

This is incorrect. You can still boot the installer with "selinux=0" on the kernel's command line, or use kickstart, which allows you to set it to permissive or to disable SELinux entirely.

What we did was take the question out of the user interface.

SELinux and Fedora

Posted Jul 15, 2008 8:53 UTC (Tue) by mauvaisours (guest, #6130) [Link] (1 responses)

I agree with mmarlowe above :
"So, as much as I agree with the principles of se linux and want it to be deployed eventually
in all production environments, I am somewhat frustrated at RedHat forcing it's customer base
to be beta testers of what essentially isn't production ready software."

For the same reasons.

BTW : Do you know of a good introduction to SELinux somewhere (principles, commands,
troubleshooting) ?

SELinux and Fedora

Posted Jul 15, 2008 17:02 UTC (Tue) by dpquigl (guest, #52852) [Link]

Dan Walsh's Journal.
http://danwalsh.livejournal.com/

This link contains a lot of practical SELinux information about configuring things properly.

If you are interested in picking up a book to learn about SELinux there is one called SELinux
by Example. It is based on FC4 or 5 but most of the information is still relevant. I own this
and the O'Rielly book and I would recommend this one.

Earlier in the comments is a page called equivocation.org which seems to have a reasonable
amount of solid SELinux information.

In addition to this is www.selinuxproject.org which contains a wiki with information.

I am also preparing a series of tutorial materials for SELinux but they are still in the works
and I need to get them reviewed by work before releasing them. However once they are public
they will be on selinuxproject.org

If you are interested more in the foundations of SELinux and its access control model there is
an email that was posted to the IETF working group mailing list for NFSv4 that provides links
to papers on why MAC is important and which explain the underlying access model for SELinux.
The email can be found the link below.

http://www.ietf.org/mail-archive/web/nfsv4/current/msg057...

SELinux and Fedora

Posted Jul 23, 2008 18:14 UTC (Wed) by andrigtmiller (guest, #53053) [Link]

I have been using Fedora since Fedora Core 3, and ever since SELinux was available, I have
been running it in enforcing mode. I must say that I have run into problems, especially early
on, and had to play with configuring things that the average user would never understand.

Having said that, today, I have virtually no problems with SELinux, and appreciate the fact
that its on and protecting me.

I do use the SETroubleShoot tool, so I see (in the UI) every time I get an access denied error
with SELinux. Most of the time, even when I do get them, it actually doesn't cause any
problems with completing the task at hand, and I then take the report from the tool and enter
a bugzilla with the information. The Fedora team fixes these issues relatively quickly when
its a policy change that's needed. The last time I had an issue, it turned out that the
policy was fine, but an underlying component was actually doing something it shouldn't be
doing, and that code was fixed. This helps to drive secure coding practices across a wide
spectrum of software, and shouldn't be lightly discounted.

If this wasn't on by default, users like myself would find it difficult to contribute to the
community effort to make this better, and the technology would just languish.

I say leave it on by default, don't give an installation option to turn it off, and let's all
use the tools provided to continue to make it better. I haven't seen a single SELinux Alert
on my Fedora 9 system in about three months, and it continues to get better and better. Let's
stay the course!