What do my Debian Community peers think of SELinux?

[cuchumino]

Hello everyone!

I've been an avid user for a little bit over a year. Debian Stable+Backports on my laptops, and Sid on my desktop.

Recently, have been working towards an RHCSA to add to my resume and using Debian my KVM host, with 3 RHEL guests running when needed for certification purposes.

I am learning about SELinux. It's got a lot of fine grain levels of access given certain contexts.... There's a lot to process, but I can see how this could be useful at a super paranoid company, Financial Institution, or Government Agency.

RHEL is all in with SELinux. I'm sure for business reasons as their market is heavily U.S. based and they are a contractor for the U.S. Government.

What is the Debian's community's take on SELinux? Is it a bit too much for the paranoid? I've heard about AppArmor, haven't touched a single bit of it though. I'm assuming it's similar for these high security users.

I've also seen that SELinux is installable on Debian. I currently don't have it installed, or am planning on doing so for any of my current machines. But, I might be deploying a Debian server for work early next year, and wanted to get a perspective from the community to see if it should be necessary, or if leaving it without is just fine too.

Thanks beforehand!

[Head_on_a_Stick]

I prefer grsec & RBAC, especially with the "learning mode"

However, I am not an expert.

More informed opinions may be found here (if anybody replies):

https://bbs.archlinux.org/viewtopic.php?id=218695

[cuchumino]

Thanks for the quick reply.

Well, I've got some time before deploying, so, I thought I'd ask the community, based off of that do my research, then take action.

I might go to the arch site and post something but I'll probably wait a bit.

[eor2004]

I simply don't trust it, it was created by the NSA, the big brother who watches us all, so no mather what level of protection it offers, I would prefer other methods of adding more protection to my pc, and one more thing, installing some kinds of software on a system like Fedora who uses SELinux since awhile now is a PITA, for example, here in Debian I can install a variety of Windows programs and games using Wine with little or no hassle, but in Fedora you have to create booleans and whatnot just to make programs to work with Wine, for me it's not worth it, and since I'm very careful about the webpages and data I download into my system, and since I haven't experienced any kind of hacking or hijacking in my pc, I dare to say that at least for me is not worth the pain in the neck, but after all it is just my opinion!

[cuchumino]

eor2004, thanks for your comment. Do you use any kind of Mandatory Access Control (MAC) software instead?

I'd agree with you on a couple of all valid points.

PITA - Agreed. All of my systems lack SELinux, except the ones that I'm using to study the RHCSA. I don't think I'd like to have SELinux and having to deal with it on a day to day basis. especially so with my wife's laptop! I can't imagine the complaints *ahem*long winded whining*ahem* that I'd get every time some kind of pop up came up, and she had no clue what it was.

Big Brother/NSA - This is another valid reason, however because SELinux is open source, and you can view every single bit that you're running, I don't think it can be that harmful to YOUR system right now if you get it from Debian's, or any other trusted distro's, repositories. There are many eyeballs on the source code of this project, not only in Debian, but also across the globe from contributers as well as other distros.

However, I can relate that it gives you an uneasy feeling in your stomach. I don't feel this with SELinux since I don't use it yet for any of my home systems. But I did feel this disgust in my stomach with Ubuntu when I was distro-hopping a little bit over a year ago. Specifically because of the Amazon spyware they added at one point to their distro. I know I can turn it off, I know that some newer versions don't have it, I know that since I would use Gnome Ubuntu I wouldn't have it pre-installed. But still... yuck.

[M51]

Big Brother/NSA - This is another valid reason, however because SELinux is open source, and you can view every single bit that you're running, I don't think it can be that harmful to YOUR system right now if you get it from Debian's, or any other trusted distro's, repositories. There are many eyeballs on the source code of this project, not only in Debian, but also across the globe from contributers as well as other distros.

The problem with that line of reasoning is that if the code is complex enough then many eyeballs are not sufficient to rule out backdoors. Look at the recent HeartBleed vulnerability in OpenSSL for an example (not saying it was deliberate, but there's no valid reason it couldn't have been.)

Sure, you can spot things like "If password=="123" then accessGranted == true" but deliberate buffer overruns, or memory use after freeing, etc. are much harder to spot and can just as easily be used to circumvent security if you know about the vulnerability (i.e. you placed the flaw in the code on purpose).

Complexity is the enemy of security.

[dasein]

...I don't think it can be that harmful to YOUR system right now...

Well if you think it, then it must be true.

There are many eyeballs on the source code of this project, not only in Debian, but also across the globe from contributers as well as other distros.

Your faith in "Linus' Law" (which would more properly be named "Raymond's Conjecture") is touching. It is also misplaced, historically speaking. There are plenty of examples of critical errors that went undiscovered for decades.

Complexity is the enemy of security.

+1

Casual perusal of code is only slightly better than nothing. And a full source audit of any nontrivial code is a mind-numbing, massive, expensive effort.

Of course, none of this is specific to SELinux. It could (and should) be applicable to any complex software, doubly so to gratuitously complex software (*cough*systemd*cough*)

[eor2004]

Big Brother/NSA - This is another valid reason, however because SELinux is open source, and you can view every single bit that you're running, I don't think it can be that harmful to YOUR system right now if you get it from Debian's, or any other trusted distro's, repositories. There are many eyeballs on the source code of this project, not only in Debian, but also across the globe from contributers as well as other distros.

The problem with that line of reasoning is that if the code is complex enough then many eyeballs are not sufficient to rule out backdoors. Look at the recent HeartBleed vulnerability in OpenSSL for an example (not saying it was deliberate, but there's no valid reason it couldn't have been.)

Sure, you can spot things like "If password=="123" then accessGranted == true" but deliberate buffer overruns, or memory use after freeing, etc. are much harder to spot and can just as easily be used to circumvent security if you know about the vulnerability (i.e. you placed the flaw in the code on purpose).

Complexity is the enemy of security.

@ M51: You've read my mind, that's exactly what I meant when I said I don't trust SELinux, no matter if it's open source, shits happens all the time, you never know if they hide some piece of code so the system sends them all things we do when we are at the keyboard.

[pylkko]

Big Brother/NSA - This is another valid reason, however because SELinux is open source, and you can view every single bit that you're running, I don't think it can be that harmful to YOUR system right now if you get it from Debian's, or any other trusted distro's, repositories. There are many eyeballs on the source code of this project, not only in Debian, but also across the globe from contributers as well as other distros.

The problem with that line of reasoning is that if the code is complex enough then many eyeballs are not sufficient to rule out backdoors. Look at the recent HeartBleed vulnerability in OpenSSL for an example (not saying it was deliberate, but there's no valid reason it couldn't have been.)

Sure, you can spot things like "If password=="123" then accessGranted == true" but deliberate buffer overruns, or memory use after freeing, etc. are much harder to spot and can just as easily be used to circumvent security if you know about the vulnerability (i.e. you placed the flaw in the code on purpose).

Complexity is the enemy of security.

This is not directly related but, I have noticed that some (all?) RUST supporters argue that C is an inherently unsafe language because it allows coders to commit many commonplace errors with memory management. For example Tony Arcieri, claims that the Hearbleed vulnerability would have been prevented with the use of RUST.

https://tonyarcieri.com/would-rust-have ... other-look

Interestingly when talking about Linux and operating systems, there is a UNIX-like micro-kernel OS called Redox OS written in RUST (I think there is some assembly, but it is ultimately a small unavoidable amount). It is quite rudimentary yet, though.

[M51]

This is not directly related but, I have noticed that some (all?) RUST supporters argue that C is an inherently unsafe language because it allows coders to commit many commonplace errors with memory management. For example Tony Arcieri, claims that the Hearbleed vulnerability would have been prevented with the use of RUST.

Speaking from experience, higher level "safe" languages can be just as unsafe as lower level ones when dealing with complex enough code. Preventing this from happening isn't possible without hobbling a language greatly. The "safety" promised by high level languages is designed to protect against accidental errors, not deliberately obfuscated ones.

The only real solution is to keep security critical code simple. This includes a lot more code than some developers seem to think it does.

[Innovate]

Nobody would want NSA messing their privacy.
I've seen Fedora communities always rant about this thing. Also I've witness from installed Fedora.
the same way that Debian/Devuan communities rant about systemd on Debian.

[pylkko]

Speaking from experience, higher level "safe" languages can be just as unsafe as lower level ones when dealing with complex enough code. Preventing this from happening isn't possible without hobbling a language greatly. The "safety" promised by high level languages is designed to protect against accidental errors, not deliberately obfuscated ones.

The only real solution is to keep security critical code simple. This includes a lot more code than some developers seem to think it does.

On the one hand I realize what you says is true. That is, that if you are thinking about possible hard coded back doors in open source code, using a language and compiler that prevents common errors is not going to solve the issue. However, on the other hand, the overwhelming majority of security risks are exploits of bad code, and even the NSA has publicly stated that such exploits are a part of their modus operandi. And you say that the only path to security is to keep the code small.. well the microkernel is exactly that isn't it?

I don't think you can hide from the NSA. Unless you stop using electronics.

http://www.linuxjournal.com/content/nsa ... rveillance

[mor]

Casual perusal of code is only slightly better than nothing. And a full source audit of any nontrivial code is a mind-numbing, massive, expensive effort.

Of course, none of this is specific to SELinux. It could (and should) be applicable to any complex software, doubly so to gratuitously complex software (*cough*systemd*cough*)

Let me follow your words with a question for everybody: where should we draw the line between trust in integrity, and 360 degree paranoia?

The way I see it, maybe because I'm totally clueless anyway even in auditing the simplest of projects, we got to have some trust at some point, otherwise everything is a potential backdoor.

The world of "linuxes", basically anything not Microsoft or Apple, has grown a solid reputation of being secure and "honest" exactly because of the possibility of peer review that should keep devs honest. It is true, you can't easily audit complex code, but it is like with scientific work, there's only so much one can grasp and verify directly about any given subject: at some point one has to trust the process of peer review even though he or she knows very well how it can be bought or tampered with.

My everyday-man reasoning is that I have all reasons to trust the Debian project for its principles and the way it works, and therefore I trust them not to put shit in my system. I certainly don't delude myself into thinking that they have everything checked out, or that some among them can't be secretly working for the forces of evil, but I trust that they are generally honest with their work and that if something shady is out of their control, it is despite their best efforts.
If it is not that then, as I said, it's paranoia-time, everything becomes a potential backdoor. Why should I trust even the notepad or the icon of my mouse cursor?
And this mindset spread easily beyond operating systems and computers (or the other way around as a matter of fact): anything can become a conspiracy, from clothes to food to medicines to cars to the water we drink and the air we breathe.

Let us all not mistake however, trust in someone for blind trust. Unlike the paranoia that kicks in and throws reason out the window the moment we no longer trust anyone, trust can (and should) still be accorded judiciously.Trust is not just given but earned and kept and lost.
Can we trust Debian?
Either we can and we trust that what they package for us is not knowingly harmful (meaning we accept the risk of them having been deceived as well), or we don't and we need to find someone else to trust.

My two cents obviously.

Take care everybody

[cuchumino]

First off, I appreciate everyone's posts and opinions. This has been VERY informative in the sense of looking at things from a different perspective. i.e. "hard core audits" vs "casual perusing" of code.

The problem with that line of reasoning is that if the code is complex enough then many eyeballs are not sufficient to rule out backdoors. Look at the recent HeartBleed vulnerability in OpenSSL for an example (not saying it was deliberate, but there's no valid reason it couldn't have been.)
...
Complexity is the enemy of security.

Hadn't thought of that. But that does make sense.

...I don't think it can be that harmful to YOUR system right now...

Well if you think it, then it must be true.

I might be at a point where I'm diving deeper into these topics, as well as questioning security, and hence the original post.

So far, I'm getting valid points from other peers, and for the most part I do trust the software that goes into Debian stable and open source software (and that the bugs are unintentional) because of the communities.

There are many eyeballs on the source code of this project, not only in Debian, but also across the globe from contributers as well as other distros.

Your faith in "Linus' Law" (which would more properly be named "Raymond's Conjecture") is touching. It is also misplaced, historically speaking. There are plenty of examples of critical errors that went undiscovered for decades.

Fair enough. I do trust this principal to a certain extent.

I know bugs/errors can be found in code, and there is always a hunt for this available. But hadn't thought of people actively looking for unknown hardware/kernel vulnerabilities to add to code, with enough cunning that it could look like a simple mistake or oversight, or have everything added seem just like good practice.

I could definitely see the NSA doing something like that.

To mor's point as well, this is why I use Debian. Things will fall through the cracks sometimes (Heartbleed), be forgotten (Dirty COW https://cve.mitre.org/cgi-bin/cvename.c ... -2016-5195), or exist through a oversight (tcp ack vulnerability https://cve.mitre.org/cgi-bin/cvename.c ... -2016-5696). Many eyeballs might miss some difficult to spot things as well.

But, Generally speaking, I trust the open source and Debian communities for reasons similar to mor's, who articulated this much better than I have.

However, I can see how many eyeballs, for example, in the SELinux project would be more likely to overlook a "well camouflaged" vulnerability or exploit if most of the eyeballs that are hardcore auditing (not casually perusing) the software are owned by the NSA.

[dasein]

I could definitely see the NSA doing something like that.

The available data are clear and overwhelming: the actual NSA primarily targets hardware, not software.

Sensible approach it is, too.