
SELinux is beyond saving - fcambus
https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxBeyondSaving
======
greglindahl
When CentOS 7 came out, I decided to make peace with all of the new stuff
(systemd) and all of the old stuff I had been disabling (SELinux.)

Turns out that doing crazy shit like letting users have their html files in
~/public_html/ requires a lot of SELinux configuration. procmail touching user
directories? Yep. spamassassin? Why, yes. Maybe there's something I did
wrong... I did read the docs.

Also turns out that there isn't a tool which tells you what new rules are
needed, relative to the existing configuration, for recent SELinux denies.
Yeah, there are some tools to spit out a complete config file based on all
logged problems, but not a diff, and I had already lost some of the early logs
to logrotate n=4 by the time I realized I needed 'em.

111 lines of perl and 116 lines of SELinux rules later, I was in good shape.
But REALLY? REALLY?

~~~
dice
The targeted policies and functionality booleans in CentOS are really nice. I
took the same step with finally buckling down and actually using SELinux for
version 6 and there was definitely a learning cliff, but just like anything
else after you've used it for a while it's all old hat.

You may have seen it already, but the CentOS SELinux HOWTO was very useful for
me in learning how to interact with it:
[https://wiki.centos.org/HowTos/SELinux](https://wiki.centos.org/HowTos/SELinux)

>Turns out that doing crazy shit like letting users have their html files in
~/public_html/ requires a lot of SELinux configuration

You should just be able to `setsebool httpd_enable_homedirs on`. What trouble
did you run in to?

>procmail touching user directories?

This works by default for me in in C6 and C7: I'm using it on a number of
production systems. The ~/.procmailrc should have type procmail_home_t but
procmail itself can create/modify/delete files in the user's home dir.

>spamassassin?

Again, should just work. You may need to `setsebool spamassassin_can_network
on` depending on configuration.

>a tool which tells you what new rules are needed

That would be nice. My usual process if I'm in a situation that needs custom
rules is to:

    
    
        echo '' >/var/log/audit/audit.log # (it would be better to rotate it here, but you get the idea)
        setenforce 0
        # Do whatever I want to be able to do...
        setenforce 1
        sealert -a /var/log/audit/audit.log

~~~
greglindahl
I read that HOWTO, actually, and the stuff you're describing isn't really
explained in it.

For example, there's a httpd example changing a label right there in the
HOWTO, and it doesn't explain where I'm supposed to discover the correct
label. And the recommended audit-script-to-config doesn't show the correct
labels, it prompts you to relax the rule instead of changing labels.

My procmail rules don't correspond to what you said procmail does. And how was
I supposed to discover procmail_home_t ?

I'm not saying I'm Mr. Super Smart, I'm just saying that it's quite a bit of
investment.

~~~
nnutter
The man pages are useful, especially once you know the basics. For example,
start at [man
selinux]([http://linux.die.net/man/8/selinux](http://linux.die.net/man/8/selinux))
in _See Also_ see the reference to [man
httpd_selinux]([http://linux.die.net/man/8/httpd_selinux](http://linux.die.net/man/8/httpd_selinux))
and in there you find every type and boolean including
`httpd_enable_homedirs`. See also, [man
procmail_selinux]([http://linux.die.net/man/8/procmail_selinux](http://linux.die.net/man/8/procmail_selinux)).

------
tjohns
It's worth noting that Android is using SELinux in recent versions for system
hardening and as part of the sandboxing model.

See:
[https://source.android.com/security/selinux/](https://source.android.com/security/selinux/)

While I agree usability is suboptimal on servers, there are definitely
environments it can excel in.

~~~
notatoad
I don't think android is really a special case, SELinux is still hard. The
only thing that makes android special is that google engineers have put in a
lot of work to make SELinux work. It's a powerful tool, but if you want the
benefits of SELinux it takes significant effort _somewhere_ in the development
chain.

------
w8rbt
Russell Coker has done some work on SELinux. He's had a Linux box online since
2008 or so that users may ssh into as root. It's really amazing to see what
SELinux can do. However, I agree that OpenBSD's focus on small and simple is
the better approach.

[https://www.coker.com.au/selinux/](https://www.coker.com.au/selinux/)

[https://www.coker.com.au/selinux/play.html](https://www.coker.com.au/selinux/play.html)

------
sn
Leaving selinux on would be more easy if the access denials were put in the
primary system log and/or in dmesg and did not just go in the audit log. It
takes too long to figure out what the problem is with selinux. That being said
we leave it on in production, since with ansible we find the problem once and
then incorporate the changes into our playbooks.

I've used both apparmor and selinux and while it was pretty easy to figure out
how to write a custom profile for apparmor, it's not easy to do the same for
selinux. If a custom profile for selinux could be made as easy to write, that
would help a lot.

~~~
cmurf
At least on Fedora, for a few releases now, the audit messages appear in the
journal, which is the primary system log.

------
ansible
For desktop Linux, SELinux is indeed difficult to use on a day-to-day basis.
To the point that there's no way I'd consider using it.

However, it is working great for Android. Where all apps are already
sandboxed, and you don't have to worry about the user installing some app that
will use a new system call, or try to touch random files on the system.

~~~
dice
>For desktop Linux, SELinux is indeed difficult to use on a day-to-day basis.
To the point that there's no way I'd consider using it.

It's on by default in Fedora, has been for years. Most people never even know
it's there.

------
nailer
When SELinux first came out I was working as a training instructor for RH.
Every single knowledgable sysadmin was kicked in the teeth by 'avc denied',
one of the dumbest error messages to ever be created in Unix.

'avc' was Access Vector Cache. The Access Vector Cache was a component of
SELinux. AVC denied meant selinux was denying access. But instead of printing
'selinux denied' \- you know, like smb messages are for samba, and postfix
messages are for postfix - the SELinux folks seemingly just wanted their
audience to do a web search for 'avc denied'.

It's a small picky thing, but rather than one person fix something, they made
every admin do a piece of research instead.

This is a pity: SELinux is one of the things that fixes the peering (aka
'Containers don't contain') issue with Docker.

------
chucky_z
May I disagree partially, using this authors exact words?

"... Unless you are a high risk target, spending almost any time beating
SELinux into shape on your machine is a bad tradeoff and pretty much a waste
..." \--
[https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxToxicM...](https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxToxicMistake)

If you are a high risk target, SELinux is a great option.

Also, to refer to the partial disagreement, here is my exact feeling...

"I'm a security aware sysadmin and yet yesterday I casually admitted that I
made less-secure choices because the really secure option was too annoying and
potentially inconvenient. In fact this is not the only case where I make this
tradeoff, picking a less secure but more convenient option..." \--
[https://utcc.utoronto.ca/~cks/space/blog/tech/SecurityNotImp...](https://utcc.utoronto.ca/~cks/space/blog/tech/SecurityNotImportant)

~~~
apkostka
I don't think you're disagreeing with the author. His statement was equivalent
to "If you are not a high risk target, SELinux may be a bad choice". Since he
used 'unless', I'm assuming his intent was the same as yours, "If you are a
high risk target, SELinux is a great option."

~~~
chucky_z
I was simply disagreeing with the title of "SELinux is beyond saving." SELinux
doesn't _need_ saving for those who have a strong use-case. There are some
great lesser alternatives like AppArmor, grsec, TOMOYO, and AKARI if SELinux
can't work for you. :)

~~~
tagrun
> There are some great lesser alternatives like AppArmor, grsec,

Lesser? grsecurity is actually a _far superior_ alternative to SELinux:
[https://grsecurity.net/compare.php](https://grsecurity.net/compare.php)

It's unfortunate that their stable patches are no longer available publicly:
[https://grsecurity.net/announce.php](https://grsecurity.net/announce.php)

~~~
mcguire
Well, unless you've been blocked from getting it by what's-his-name.

------
noonespecial
SELinux worked and worked well _when you knew how to use it_. (Learning how to
use it was also reasonably hard.) Its primary problem was that its default
behavior was stuff mysteriously failing on your system. This made it very hard
for the uninitiated to get into it when stuff all over the web just
recommended "turn off SELinux" as the first thing to do when something wasn't
working right.

It got a bad reputation as that quirky security thing that keeps stuff from
working all the time.

------
timthelion
While I have nothing against SELinux, I feel that modern solutions using
containers have made it almost irrelivant.

And now some SE supporters are fighting back in the dirtiest way possible.
[https://opensource.com/business/14/7/docker-security-
selinux](https://opensource.com/business/14/7/docker-security-selinux) Mr.
Walsh makes all sorts of claims about things, such as devices, which are never
exposed to the container, not being namespaced. It is very bad when someone
who is respected and has qualifications goes and spreads lies and
insinuations, just because their product is no longer relevant.

~~~
tjohns
I thought that Docker containers were primarily intended for environment
isolation, not for security?

As I understood it, Docker relies on the kernel enforcing syscall namespaces
for security... and that there's a (admittedly small) possibility of container
breakouts via this route, because of the large surface area involved.

Even the Docker devs have a whitepaper that recommends running Docker inside a
VM when multi-tenancy is involved, as part of a defence-in-depth strategy:

[https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Se...](https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Security/WP_Intro_to_container_security_03.20.2015.pdf)

~~~
cyphar
Docker uses SELinux, seccomp and apparmour as well as stock Linux capabilities
(in conjunction with namespaces) to reduce the attack surface exposed to a
container.

There's nothing inherently insecure about containers (look at FreeBSD and
Solaris). The issues you see with Linux "containers" are usually caused by
leaky abstractions (namespaces that don't namespace the entire kernel) and
insufficiently clever setup scripts. But it is getting better.

------
waspleg
I confess to disabling SELinux being one of the first things I always do on a
new Linux box. It gets in the fucking way. A lot.

~~~
matt_wulfeck
It works great on really mature platforms where the engineer has time to fine-
tune and troubleshoot SELinux issues every time a change is made...

But who the heck has the time for that now-a-days?

------
educar
Configuring SELinux reminded me of configuring email. My god, can simple
systems be made more complex than this? I mean it's email and yet you have to
really struggle with 100s of options to make sense of it all (and you do know
sendmail has no public repo with a proper revision history right?).

Apparmor, in contrast, is much easier to use (granted it has it's warts) but
atleast they are trying to be user friendly instead of mathematically
complete.

/rant

~~~
djsumdog
I remember going through hell trying to build an apparmour profile for an app
at my last job (a Python app, which makes this a bit more complicated with
interpreters, wrappers, external commands and such).

I did get it built and the built in tools for aa are decent.

I've never had to develop and SELinux profile. Now I don't ever want to.

~~~
educar
I feel I need to quality what I meant by 'much easier'. AA is exactly as you
made it sound - actively asocial. Now imagine how SELinux is ;)

------
chris_wot
I'm sure it's not intentional, but the author spends quite a lot of time
telling me that the SELinux folks aren't listening or learning what the real
issues are in security, but try as I might I all his links to his blog posts
he doesn't actually state what they are!

What are the key issues that SELinux needs to address?

~~~
viraptor
One repeated many times is that it's complex enough that people default to
turning it off. But it doesn't even come from users sometimes. Just google the
following: installation instructions "setenforce 0"

How many projects just went the lazy way? How many projects went out of their
way to fix the issue the wrong way?

Notice how nagios documentation first tells you how to disable selinux for the
whole system and make it permanent. Only then as an alternative gives you two
lines to make it work correctly instead.

So what can SELinux folks address? Submit a change to every documentation in
that list with instructions on how to make selinux work without issues. And
make sure the alternative of "setenforce 0" has a warning that this will
disable protection of your whole system rather than just this app.

------
api
Complexity is evil in security, and opt-in security generally doesn't work.
SELinux is both complex and opt-in.

~~~
ybx
You can make it enforce rules strictly over everything, rather than
selectively enforce it on specific applications.

~~~
throwaway2048
no software is written with this in mind, so it wont work right without
extensive babysitting (that nobody will do).

------
vardump
SELinux is still nice for hardening a safety critical server.

But configuring it sure isn't fun.

------
kevin_thibedeau
The post succeeds at saying nothing concrete about actual deficiencies in
SELinux beyond "it gets in the way". Yes of course it does. That's what locked
down systems do even if it's only to shoulder the blame for breaches on admins
who disabled protections.

~~~
drauh
My experience with it was on RHEL4.x some years ago, trying to install a bunch
of stuff not from the official repos or EPEL. (I think it was Puppet, at the
time.) Holy crap. It took me a week. It was more complex (or, almost
equivalently, poorly documented) than the old AT&T Merlin PBX+voicemail
system.

The only thing I recall offhand was the hugeness of the namespace for roles
(?) and actions (?). Every time I punched a hole to allow a specific thing to
happen, something else blocked the action with cryptic logs in obscure places.
I felt like a blind person, trying to find their way through a maze.

------
matt_wulfeck
SELinux is not not worth saving because security has been moving steadily into
namespace separation (E.g., containers, virtual machines).

Giving an application/user and entire trimmed down OS namespace reduces damage
done from getting pwned significantly. Why use a system that protects
processes from running alongside each other when I can just give them their
own, fenced-in home?

~~~
viraptor
No. No, no, no. Virtual machines - yes, to an extent. Containers - no.

Containers still use the same kernel, have access to the same filesystems (in
practice), same devices, same ioctls, etc. There can be a lot more separation
done in the future, but right now, you definitely gain a lot by isolating your
containers using selinux.

Even with virtual machines, you want any breakout / external write
vulnerability to be contained. That's why libvirt/kvm _relies on selinux_ (or
apparmor) for system protection and for cross-vm protection
([https://libvirt.org/drvqemu.html#securityselinux](https://libvirt.org/drvqemu.html#securityselinux))

~~~
djsumdog
I felt the same way about Docker containers. Now I work for a company that
uses Docker containers in production.

The fact that the process, by default, runs as root and PID 1 within the
docker container still has be going "You gotta be fucking kidding me?!"

I realize Docker has come a long way since the days of it being LXC based.
Cgroups and several other safeguards have done a lot of docker security, and
containers are much more lightweight than full VMs, but I'm still a little on
edge about the security aspect.

~~~
teabee89
Since Docker 1.10, you can specify --userns-remap=default on the daemon and
root inside the container will not be root outside:
[https://docs.docker.com/engine/reference/commandline/daemon/...](https://docs.docker.com/engine/reference/commandline/daemon/#starting-
the-daemon-with-user-namespaces-enabled)

~~~
e12e
I have the impression that regrettably many docker users expect things to be
the other way around: that the actual default docker behaviour resides behind
a --ridiculously-insecure, not that you need to specify --i-actually-want-my-
container-to-try-to-contain to get that expected behaviour.

Hopefully more people are becoming aware of the actual default behaviour.

------
mgbmtl
The article (and the comments here) encouraged me install SELinux on one of my
(Debian) VMs to see how it goes, and I'm now wondering why I didn't try it
earlier.

------
zanny
If you are a security purist, why aren't you using grsec / pax / rbac in the
first place? The general totem pole is grsec rbac is king > Apparmor is a
destitute wannabe hacked together disaster that is still more usable than
SELinux > Archlinux doesn't give a shit while Red Hat is off doing their own
thing with SELinux with the NSA and Google.

------
kkirsche
Do people see this as something though which should be or needs to be replaced
or is this just a it's dead? If the first, are there any projects I could
contribute to or is a new project needed?

------
cryptos
What to use instead of SE Linux?

------
Endy
And this kind of crap is why I use Windows.

~~~
a3n
Ah yes, Windows, where you wake up one day and have a completely different OS.

~~~
hulahoof
That whole one time leading into 95 (b.")b

~~~
jessaustin
I detest Windows and touch it as rarely as possible, but _this week_ I had to
make an emergency trip to a client's office to re-share a folder after a
server had "upgraded" itself from 7 to 10.

------
TimPrice
If he calls himself a security aware sysadmin but he is somehow breaking his
own beliefs for productivity/delivery reasons, I don't see much of an
interest.

Let him rant all he wants on his blog. Back to work.

