SELinux and Fedora

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.

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.

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.

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.

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

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

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]

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.

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.

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?

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

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.

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.

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!