Security-enhanced Linux for mere mortals - 2015 Red Hat Summit

Thomas Cameron - Chief Architect, Central US, Red Hat, Inc.
In the past, security-enhanced Linux (SELinux) had a reputation as being hard to configure and maintain. Often, Linux admins would turn it off. But SELinux is an important part of a broad security strategy. SELinux is now a foundational part of important technologies like Linux containers, and drives security and scalability in Platform-as-a- Service (PaaS) offerings like OpenShift.
Through the hard work of the SELinux Community, SELinux is now easier to manage than it ever was in the past.
In this session, you’ll learn the basics of SELinux, including how to:
-Configure SELinux.
-Analyze and correct SELinux errors.
-Set rules and create basic policies to allow applications to work on SELinux-protected systems.
We’ll use real-world examples to demonstrate how to use SELinux.

[@Nutsacjac1]

Thank you for uploading this!

[@RaymondChen]

Thank you so much, Thomas. This is so helpful. Now I know why my VM hung when I set it to enforcing and rebooted.

[@orever]

I really appreciate that these videos are available for free, but the constant panning of the camera is very irritating.

[@jerther_]

The 2013 one on the same matter if barely watchable.

[@undefined879]

As I've mentioned before, I started out with SELinux turned on on my laptop because it's essentially a stock Fedora install and that's how Fedora defaults, and using SELinux felt virtuous. Last year I reached the end of my patience with running SELinux in enforcing mode, where it actually denies access to things; instead I switched it to permissive, where it just whines about things that it would have forbidden and then a whole complicated pile of software springs into action to tell you about these audit failures with notifications, popup dialogs and so on. Today I gave up on that. My laptop now has SELinux disabled entirely (as my desktop machines have for years). The cause is simple: too many SELinux violations kept happening and especially too many new and different ones kept coming up. I am only willing to play whack a mole on notification alerts for so long before I stop caring entirely, and I reached that point today. The simplest and most easily reversed way to stop getting notifications about SELinux violations is to set the SELinux policy to disabled in /etc/selinux/config, so that's what I did. It's possible that some of the problem is due to just upgrading to Fedora 22 with yum instead of, say, fedup, and perhaps it could be patched up somewhat with 'restorecon -R /'. Perhaps a wholesale reinstall would reduce it even more (at the cost of putting me through a wholesale reinstall and then figuring out how to set up my environment and my account and keys and wifi access and VPNs and so on all over again). Certainly I assume that SELinux has to work for some people on Fedora. But I no longer care. I am done with being quixotically virtuous and suffering for it.

[@anthonyjones5962]

great video just what i needed to fix my issues thank you

[@v1rtu4l]

that was very informative =)

[@yoshi314]

now i really feel like trying out selinux, this looks fairly usable.

[@aswinivayyala5118]

Great presentation with real world examples. Have to give it to the guy to keep the presentation super interesting.

[@phillipodam994]

Yeah great presentation Thomas, I've been using various distros of GNU/Linux for about 15yrs and openly admit to be a long time member of the setenforce 0; sed -i -e '/SELINUX=/s/enforcing/disabled/' /etc/selinux/config but at the same time I'm a strong believer in security / defense in depth and while SELinux can at first be hugely daunting (been putting it off for years as DAC seemed sufficient for my needs) it's only ended up taking a few days to not just get my head around it but also worked out exactly what I need to work within our production environment... well a bit of help from people like Dan Walsh perhaps. I can certainly see why SELinux won't be something people will be too accepting for their personal pc unless the policies shipped with their favourite apps are 100% but for servers the barriers like you've shown have really come way down. And a little immediate convenience trade off for a nice boost in security only makes sense to me, besides it's not too convenient when you find out you've been broken into.

[@KoflerDavid]

Love it :-) hope it helps me to make Apache in a container work

[@PierreYvesLochou]

Hello! Is there some equivalent written paper somewhere? Thank you very much!

[@ThomasCameron]

people.redhat.com/tcameron/

[@threeone6012]

If you've got nothing better to do over the next 2 years you can become great at SELinux.

[@jasonmicron]

Someday the people at Red Hat that say things like this, yet never touch production systems in enterprise environments will realize that living in a bubble and assuming it's their way or the highway is no way to go through life.

[@kbdkbd99]

completely agree with you Jason - whenever I hear someone saying something like "ye I was using SunOS 4 back in the day", (OSF, Irix (Silicon Graphics), DEC Ultrix whatever) -- it usually means they are trying to persuade me of something by implication and I'm the worlds biggest sceptic !! :-)) anyhows - its a good talk so I rated it up.

[@zootytheduck4800]

Disable iptables, disable selinux, chmod 777 all the things because who needs security?

[@dylantaylor490]

+Zooty The Duck Why not set password to an empty string and enable root login remotely without a password while you're at it for good measure?

[@Tech-Learning]

But really disable selinux, today only I got into a situation in which, I didn't touch anything on selinux, just installed a new package and its dependencies and after that, no one, really no root, no system admin, no other user was able to log into the server. I had no idea what happened. after restarting server (in about 4 hours after a long mail chain with datacenter) I came to know selinux does everything. Why why why, the fucking selinux messed up whole server. It makde RHEL look bad as a server, once you install something on RHEL you need to restart the server in single user mode to resolve the issue caused by SELinux. Yes what the site stopdisablinselinux.com say Dan Walsh deserve to cry, his SELinux was just going to make me jobless while I was not event touching it. Ubuntu and Debian are so successful without SELinux why Redhat need it. Why? Now onwards If I can get access to any system to setup, if it has SELinux I will simply try to unsintall selinux packages. Not only disabling them but completely erasing SELinux from the system.

[@zootytheduck4800]

Dylan Taylor that's good advice, I'll remember that!

[@geicogecko8524]

Don't forget to run rm -rf / at work

[@YumekuiNeru]

rm /bin/rm

[@fukRiaa]

Or if you care about security on an internet facing server you could install OpenBSD which puts much more emphasis on getting the code correct in the first place and has far fewer CVE's than any Linux distro instead of just bolting on a clumsy RBAC system and pray it tangles up the horse as it leaves the barndoor but is acutally much more likely to kick the farmer in the groin.

[@Tech-Learning]

I think debian is also better than REDHAT if redhat don't stop their SELinux junk.

[@Aduskett]

Ahahahahahaha Debian is god awful dumpster-fire garbage.

[@truboxl]

Still open Bugzilla report though...

[@undefined879]

When people say 'this security tool is too hard to use, gets in my way, and isn't giving me any real benefits', telling them 'it's great if you only spend more time learning how to deal with it' is doubling down on your problems. If you then compound things by telling people that they are just stupid and lazy, don't be surprised if they immediately tune you out because you're acting like a zealot (you may or may not be one, it doesn't matter to people). It's been apparent for years that SELinux had serious problems in real life (regardless of what the theory says). For example, it's widely considered standard practice to disable SELinux immediately on server installs (as mentioned in the Twitter thread I got this from). The reason people reject SELinux in its current state is pretty simple: security is not their top priority. 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 (partly because SELinux is just a backup).

[@BenGosney-dog]

I'd agree with you if this wasn't aimed at sysadmins.

[@undefined879]

In the face of this, for the SELinux community to feel that people are stupid, lazy, or ignorant for not jumping through the magic SELinux hoops and all would be well in the world if only they would mend their woeful ways is breathtakingly stupid and counterproductive. At a stroke it sabotages almost any chance SELinux might have to actually make meaningful improvements. Not that such improvements would be easy even if the SELinux community listened to what the world was telling them (because it's a hard problem), but if the community did listen they might at least have some sort of chance. (Not that this sort of blindness is new in security or in general.) (What I think the SELinux community should be doing is a sufficiently large issue that it doesn't fit in the margins of this entry. Of course it's an open question if SELinux can be saved or is worth saving in general given its origins; I think there's a real argument that SELinux's security model simply does not meet people's real security needs by design.)

[@tomatobros]

NSA grade security topkek.

[@cuszco]

en.wikipedia.org/wiki/Security-Enhanced_Linux

[@undefined879]

SELinux has problems. It has a complexity problem (in that it is quite complex), it has technical problems with important issues like usability and visibility, it has pragmatic problems with getting in the way, and most of all it has a social problem. At this point, I no longer believe that SELinux can be saved and become an important part of the Linux security landscape (at least if Linux remains commonly used). The fundamental reason why SELinux is beyond saving at this point is that after something like a decade of SELinux's toxic mistake, the only people who are left in the SELinux community are the true believers, the people who believe that SELinux is not a sysadmin usability nightmare, that those who disable it are fools, and so on. That your community narrows is what naturally happens when you double down on calling other people things; if people say you are an idiot for questioning the SELinux way, well, you generally leave. If the SELinux community was going to change its mind about these issues, the people involved have had years of opportunities to do so. Yet the SELinux ship sails on pretty much as it ever has. These people are never going to consider anything close to what I once suggested in order to change course; instead, I confidently expect them to ride the 'SELinux is totally fine' train all the way into the ground. I'm sure they will be shocked and upset when something like OpenBSD's pledge() is integrated either in Linux libraries or as a kernel security module (or both) and people start switching to it.

[@GuillermoQuinteros_]

setenforce 0

[@tonytheleg801]

FFS thank you for this video. The theory made total sense, but the implementation didnt.

[@Tech-Learning]

Disable Selinux, you don't need it, anything can be done without using SELinux. But if you enable it, you will have a lot of issues. Like I got on my production system. Would you like the situation in which you install a small binary with its dependencies thorugh yum and think I am done. Log out the terminal and login back and you are getting authenticated but before getting shell it get automatically logged out. Ohh, why? am I the only person to experience it on that system? No, Any user on that system was not able to login even on VM console. Everyone was getting logged out as they logon. Then we called datacenter and restarted a production server (in weekdays) in order to fix the selinux to disabled in order to resolve the issue. Why not disable it before it bring you to such situations.

[@McNubblet]

You should probably consider learning about test/staging/production machines to sort out these problems before they arise. SELinux is great if you take the time to learn it (it's really quite simple when it comes down to it) - this attitude is one of ignorance - "i can't figure it out, so it must be bad" doesn't really help anyone at all.

[@Tech-Learning]

Yes I know, but I am not the developer of selinux. I was deploying the tested build on production. Its not I don't know, its WTF, this shouldn't happen enen in my dev system if I use SELinux. Selinux shouldn't force you to single user mode. Its ignorence by selinux developers not me.

[@marcobulgarini5252]

I'm just pitching in to say that the ignorance is definitely yours, not knowing that a simple "setenforce 0" could have reduced the impact on a production env. And if you don't know this simple one, you probably can't guess a lot of stuff else. ...and all of this from a "SElinux disabled" guy - at least, until now.

[@Tech-Learning]

Marco Bulgarini Yes the ignorance is basically from the system admin who setup the server I agree. You are right. I was just setting up my application there. So, either the system administrator should setup the application or I should manage server, as I already instructed them to run "setenforce 0" with permanent change in slinux settings. Thanks for commenting.

[@marcobulgarini5252]

+1 on having a good documentation on everything prod. A general rule I follow is: if it's live, no dark spots - ESPECIALLY if it's bound to be troubleshooted like SElinux.

[@NickFoxQuixand]

This guy is kind of annoying

[@Nicrame]

52 minutes about security enhancement that is for mere mortals? Really? Please check how easy Windows firewall is easy to setup, then compare it, and we may talk about what means simple to use and configure...

[@BenGosney-dog]

Please check what Windows Firewall does and then compare it to what SE-Linux does, then rethink your comment. If you were comparing Windows firewall to IPTables, I'd be right there with you.