Comment by throwaway7767 | Hacker News Reader

Comment by throwaway7767 | Hacker News Reader

Parent Full thread

I feel like what SELinux is missing is an extra layer of abstraction for the configuration, to make it easier for humans to work with.

The "Just disable SELinux!" sysadmin answer strikes me as coming from the same place as "Just disable IPv6!" and "Just disable PulseAudio!" - a lot of sysadmins don't like having to learn new things. I've done sysadmin work for about 20 years now, and I don't share that view - learning new things is a necessity in this line of work. You either learn a new thing you can apply in your work, or you find out it's not a good solution and now you have an informed opinion on why it's not good.

You mention AppArmor as a "more practical security measure" being held back by SELinux. But Chris's blog post states that they disable that too. In essence, his argument seems to be "I don't really care about all this security stuff, I just want it to work the same way it always has". I understand the viewpoint, but that's not the way to progress.

Our viewpoint is ultimately pragmatic: at the moment, both SELinux and AppArmor appear to be too much work for the potential benefit they offer in our environment. We could spend a great deal of time configuring both of them in order to make things work, and they would still probably not do anything much for us in practice.

(Remember, both SELinux and AppArmor are secondary defenses, not primary defenses; they potentially limit the damage if your system is already partially compromised.)

In part this is because at least SELinux only really works easily if you put everything in what the distribution considers its standard location and run things in the standard way. The moment you deviate from this, you wind up having to research an increasingly large number of file and executable contexts and (re)label an increasingly large number of files. And I'm ignoring NFS here, which we use heavily (I doubt NFS files can easily have SELinux attributes, especially when they live on non-Linux NFS servers).

Security is always ultimately about pragmatics. You have X amount of time to spend on security in all its aspects, and you need to use this time efficiently, to gain as much security from it as possible. Our judgement is that use of our security time configuring SELinux does not have a particularly high payoff.

(For clarity: I'm the author of the entry that mwcampbell linked to.)

Hi! Thanks for your ZFS entries, they've been very useful to me in the past.

I understand the pressure of not having enough time to do things perfectly. But the kernel is a project with widespread use in many domains, and the security features it implements have to provide strong security. We can't let kernel security requirements be dictated by environments that don't believe they require them. It's possible to set up a much less restrictive SELinux environment if you don't need or want to get the full benefit.

This also comes in to my first point, which is that we really need a better abstraction for SELinux configuration. Something that would be simpler to administer for environments that don't require the utmost in security isolation. But it should build on the strong in-kernel MAC implementation that already exists.

The general SELinux issue is a complex subject. My short form take is that regardless of its potential in theory if implemented nicely, in practice SELinux as deployed has consistently prioritized mathematical perfection (and yelling at people) over practical usability in the field. The real result of this has been less security than would have been achieved with a less perfect but more usable system because in the field SELinux does not degrade gracefully and so many people turn it off entirely. Some number of systems are quite secure (assuming no leaks in SELinux itself); many other systems are not secure at all. This is a bad outcome (unless you decide that only people who are dedicated enough to use SELinux really matter and everyone else is 'unprofessional' or the like), and I don't like it. I want a better outcome, one with more security that I can actually justify deploying, one where more daemons and programs are hardened to some degree even if it's not a huge amount.

(At this point the OpenBSD pledge() work is looking attractive, although there are real organizational issues that would make it hard to do in Linux.)

Perhaps one can get to a better future with SELinux by having people build and ship systems for doing little SELinux configurations for daemons or systems that read daemon configuration files so they can automatically label directories and files for your system, or any number of other user friendly ideas. But we've had something like a decade of SELinux and its usability problems at this point and it hasn't happened yet. It's hard to avoid the obvious collection of conclusions.

SELinux came from the defensive side of NSA, pre 9/11, and was not written to make Linux more secure. It was written to force application developers to re-architect their applications so they could run under a mandatory security environment. The original idea was that, once enough applications could operate under a mandatory security model, an secure OS could be put in underneath them.

NSA had had several multi-level secure operating systems developed for them in the past, but they didn't have any applications other than ones specifically written for them. SELinux was intended to remedy that.

Unfortunately, nobody seemed to understand that, and NSA doesn't do much outreach.

> PulseAudio

I abhor PulseAudio, because it just doesn't work as smoothly as JACK or ALSA. Sometimes learning a new thing isn't necessary, as the old ways of doing something still hold.

I agree with the BSD way of doing this: force it on the users and try and help them come to terms with your changes. If there's a revolt and/or it's too much work for you, revert. Otherwise your entire ecosystem is safer.

In my experience, most of the problems people have with PulseAudio come down to buggy ALSA drivers not handling buffer resizing correctly. Adding tsched=0 as a module option "fixes" that by making them not export the buggy interfaces. The result is much the same as playing directly through ALSA.

The reason PulseAudio wants to use these interfaces is that it has to make a tradeoff between CPU utilization+battery usage versus low latency. If you use ALSA directly, the first application to open the device controls the size of your buffer. The first client was a music player requesting a large buffer? Then your SIP client will get high-latency audio. PulseAudio tries to fix this by dynamically resizing the buffer.

I'm sure there's actual issues with PulseAudio, but somehow most of the problems I see people complain about lie further down the stack.

Of course, discussion of pulseaudio is rather off-topic here, it was just one more example of how "just shut down the new thing!" is often easier than diagnosing the actual problem.

-1 on PulseAudio. I used to be ambivalent on the entire thing until I experienced a proper jack setup (KXStudio).

Having a visual interface to plug/sort sound inputs and outputs seems trivial, until you see someone running their skype conversation through FL Studio (in Wine!) to distort their voice using autotune, and then back out to the inputs. Or recording vocals over skype, filter with reverb, and sending them back over skype to the singer. in realtime. this stuff is _trivial_ in KXstudio.

Pulseaudio is still struggling with "Front Left", and "Front Right" both playing audio whilst getting in a fistfight with alsa. in 2015.

I'm building a (private) linux distribution for my corporations' chromebooks, based on gentoo/calculate KDE. I plan to avoid everything lennart poettering has touched. It'll be simultaneously vindicating and frustrating how my users will be saying "wow. you can do that in linux?" again.

The best experience I have with PulseAudio is by layering it on top of JACK.

Reply on news.ycombinator.com