[nicce]

AppArmor is easier to understand because it is simply less restrictive, and in that way it is less effective solution. I would not call SELinux as poor design choice because of that. You can't do things with AppArmor that you can with SELinux.

[generalizations]

You can make your security as granular as you like; but it's just like any other architecture in that you have to come up with good abstractions that make it usable. SElinux is simply poorly designed.

[miah_]

Its because Selinux wasn't really designed for "sysadmins" it was designed for "governments" or organizations that need to meet a specific level of security as a contractual/legal requirement. Selinux came out of the NSA and is based around the Trusted Systems Criteria / Common Criteria, aka the Rainbow Books. If you look at 'Trusted Solaris' (or IRIX, AIX) you'll see very similar systems.

Is this poor design or simply, not designed _for_you_?

I agree, its a royal pain to manage, and it might be overkill for a small shop trying to lock down their web server. Thankfully there are other solutions, and operating systems that may better fit your use cases.

https://en.wikipedia.org/wiki/Common_Criteria

https://en.wikipedia.org/wiki/Trusted_Solaris

https://en.wikipedia.org/wiki/Security-Enhanced_Linux

[taikobo]

Well put, so to rephrase: SELinux is not for most people and cooperation, therefore, it is sensible to just disable it, making RHEL less secure than Debian in practice.

[ruthmarx]

Very much the wrong takeaway. SELinux is absolutely for people and corporations and has been for most of it's existence, and no, it doesn't make sense to disable it anymore than it makes sense to run as root because it's convenient.

If you are looking for a justification to excuse bad security practices, you won't find it in the origin story of SELinux.

[miah_]

Its very much for people who are trying to lock down their systems. Its also very much for people who want to meet the Common Criteria. It can be both. But for some people, its very much over kill.

[generalizations]

I mean yeah. It's software designed for compliance. It's technically capable of any kind of restriction a bureaucrat might envision, so it's the best thing available for the kind of checkbox security needed in a regulated industry.

I find it enlightening to read what kinds of justifications the proponents of SElinux use. It's never about the quality of the software; it's about how there's more band-aid tooling to make it easier to work with, or about how it's not as bad as it was, or that it gives you all these knobs and levers to have more control. It's not what you focus on when you're serious about quality software engineering.

Imagine if we were talking about something like Gnome or the Windows 11 interface: yeah, the interface is a real pain to navigate, but we added even more menus and buttons and the rightclick menu is twice as long now, so you can do even more stuff with it, and we even added Clippy back in to help you when you get stuck!

[SubjectToChange]

Yes, SELinux is enormously complex and typically obtuse. However, it's difficult to imagine a much more "elegant" solution for the role SELinux serves. Linux, and Unices in general, are simply not designed for security. Indeed, the virtualization movement was largely driven by process isolation being so poor in mainstream operating systems.

SELinux is designed to fulfill to primary goals. First, to secure the messy and complicated Linux architecture. And second, to be flexible enough to accommodate (highly) complex security architectures, as well as potentially unique and/or unforeseen needs. With that in mind, it's difficult to imagine any equivalent being practically more simple and/or elegant than SELinux.

The primary problem with SELinux is the broad lack of experience amongst users and sysadmins, opaque documentation, and primitive tooling. And in many ways, it is a negative feedback loop. If SELinux was used everywhere, improvements to its documentation and tooling would naturally follow.

[generalizations]

Some variants of Unix are designed for security; OpenBSD comes to mind. And Theo is on the record eviscerating the notion that virtualization be used as a security measure. Something about complexity being counterproductive to a secure system.

You're describing the linux architecture as messy and complicated, but that describes the SELinux architecture as well; if complexity & mess are bugs that should be squashed in pursuit of security, SELinux is ill-suited to the task.

> And second, to be flexible enough to accommodate (highly) complex security architectures, as well as potentially unique and/or unforeseen needs.

>> It's technically capable of any kind of restriction a bureaucrat might envision

Sounds like we're on the same page there. Or at least looking at the same phenomenon.

Your last paragraph is definitely outside the pattern of justifications I listed, but it's not much better: you're just blaming the users. Sysadmins use all kinds of complex software to accomplish any number of delicate tasks - if the tool is well-built, they don't tend to complain that it isn't. SELinux is not. Don't blame the user when the tool's at fault.

[ruthmarx]

> Some variants of Unix are designed for security; OpenBSD comes to mind.

This is fundamentally not true. Don't buy into the aggressive marketing. OpenBSD has a less secure design than pretty much any modern Linux. Their reputation for security is based on disabling things by default when it wasn't common 20 years ago, that's pretty much it.

[pjmlp]

There are some talks on the actual security OpenBSD provides in practice.

[SubjectToChange]

...Theo is on the record eviscerating the notion that virtualization be used as a security measure. Something about complexity being counterproductive to a secure system.

Hypervisors predate Unix, in fact they practically predate general purpose operating systems as a whole. The reason hypervisors came first is because they are substantially more simple than an OS. Tens of billions of dollars has been spent on virtualization technologies because of its reliability.

Sure, a virtual machine running on a type-2 hypervisor like KVM looks like a complete mess. But the sad part is that such an architecture is easier to secure than an operating system, whether OpenBSD or otherwise. Raadt may disagree, but AWS, Azure, GCP, etc depend on hypervisors/virtualization, not OpenBSD.

You're describing the linux architecture as messy and complicated, but that describes the SELinux architecture as well...

Well, yes. SELinux has to cope with the deficiencies of Linux. I'm not pretending otherwise.

...if complexity & mess are bugs that should be squashed in pursuit of security, SELinux is ill-suited to the task.

The problem is that the market settled on Linux, despite its "complexity & mess". SELinux isn't nice but it's the most concrete solution available today. Indeed, after twenty years of criticism, no one has been able to design a competent replacement or alternative.

>> It's technically capable of any kind of restriction a bureaucrat might envision Sounds like we're on the same page there. Or at least looking at the same phenomenon.

There is a material difference between our viewpoints. The government has systems running in a dizzying amount of configurations and environments. Moreover, government agencies and government contractors operate in a far more dangerous security environment than the vast majority private companies. Perhaps your workplace doesn't need SELinux, but companies like Lockheed Martin or Aerojet Rocketdyne definitely do.

...you're just blaming the users.

Maybe it seems like splitting hairs, but I'm not blaming anyone. Rather, I was lamenting over the bad situation of things. After all, I've been there as a new sysadmin. Trying to grok SELinux for the first time is not a pleasant experience.

Don't blame the user when the tool's at fault.

Look, if security isn't important for someone and/or their organization, then fine, don't bother. However, we have seen time and time again that compromises in supposedly "unimportant" systems ends up causing quite a bit of harm.

Ultimately SELinux exists because of the shortcomings of Linux itself. Nothing has replaced SELinux because genuinely securing a Linux system is extremely difficult and it fundamentally cannot be made simple.

[okasaki]

Poorly designed for general use?

[SubjectToChange]

Securing Linux, or practically any Unix system for that matter, is like nailing jello to the wall.

[commandersaki]

And if you want to see something that is the pinnacle of design in this space, go no further than openbsd pledge and unveil. Out of band policies is an ugly way of doing this.

[candiddevmike]

Sorry, I was responding to the parent's question about why one was disabled over the other. Yes, SELinux is more capable, at the cost of additional complexity. I think it's debatable how many companies need that complexity, especially outside of the federal space.

[vundercind]

I’d bet money the main practical purpose SELinux serves is to check boxes when negotiating government contracts, in a way that’s familiar and can be called a standard.

Then in practice someone ends up writing a couple policy statements and filing a couple forms then disabling it anyway, nearly every time.

If that’s the case it doesn’t need to actually work in practice, just hypothetically.

[ruthmarx]

I've never seen SELinux as a requirement for any auditing, and I've done a fair amount of auditing.

It's not the only project like it, it's the one that is most well known because it has the NSA attached and because it got incorporated into the main kernel.

It works in practice, absolutely, but most people are too intimidated or lazy to put in the effort to learn it.

[craig_s_bell]

For some distributions, CIS benchmarks (also used by various other security tools) now include guidelines for SELinux.

I couldn't find it in the Debian spec (probably because it uses AppArmor), but the RHEL benchmark has these.

Currently, server level 1 only requires permissive mode:

https://www.tenable.com/audits/items/CIS_Red_Hat_Enterprise_...

  CIS Red Hat Enterprise Linux 9 v2.0.0 L1 Server — 1.3.1.4 Ensure the SELinux mode is not disabled

... While server level 2 specifies enforcing mode:

https://www.tenable.com/audits/items/CIS_Red_Hat_Enterprise_...

  CIS Red Hat Enterprise Linux 9 v2.0.0 L2 Server — 1.3.1.5 Ensure the SELinux mode is enforcing

[rlpb]

A solution that people disable in practice is the least effective solution.

[NewJazz]

Can you offer some examples of things you can restrict with SELinux that you wouldn't be able to with AppArmor?

[mhitza]

Limiting services to a limited set of ports, if this forum post is still relevant today https://ubuntuforums.org/showthread.php?t=1780657

Regarding how to do that, it's left as an exercise to the PhD holding student.

[goneri]

This is one of the topics of the article.

[vlovich123]

Having read the article I could not find any example of what is impossible in AppArmor, just a statement repeated in various ways that SELinux is easier to provide a secure-by-default environment with the closest thing to justification being that SELinux models things with types whereas app armor deals with restrictions on specific applications. I’m sure this all makes sense to someone already well-versed in the space, but I’m left with the same question as OP.

[ruthmarx]

> I could not find any example of what is impossible in AppArmor,

AppArmor is simply less granular. For example, it doesn't provide true RBAC or MLS security models. It also uses paths instead of inodes, so a hard link can be used to override some policies.

So it just depends on what the exploit or attack is trying to do. If an attacker gets root and is trying to overwrite a file, they may be able to. Maybe they can't, but they could probably still execute any code they can write and compile themselves. And perhaps they can write to other files and do damage.

SELinux and similar systems allow a lot more granularity. Programs and users can only talk to explicit what they are allowed to talk to, and maybe you want to limit the access to say, append instead of full write access.

It just allows a lot more granularity and restriction, that's the difference.

[NewJazz]

> It also uses paths instead of inodes, so a hard link can be used to override some policies

The link rules can get pretty granular and seem explicitly designed to prevent that scenario.

https://man.archlinux.org/man/extra/apparmor/apparmor.d.5.en...

> they could probably still execute any code they can write and compile themselves

Assuming the AppArmor profile allows writing to and executing the same files. Which isn't particularly common.

> maybe you want to limit the access to say, append instead of full write access

This is possible with AppArmor.

[ruthmarx]

> The link rules can get pretty granular and seem explicitly designed to prevent that scenario.

It's still an inherent weakness. No getting around that really.

> Assuming the AppArmor profile allows writing to and executing the same files. Which isn't particularly common.

I don't really want to try and come up with examples just so you can show there might be some hacky way of accomplishing something similar to what SELinux can offer - it would be missing my point.

Point is there's a lot more you can do under AppArmor than SELinux. AppArmor isn't as granular and you can't lock down a system to the same extent, period. Is it good enough, sure. Is it better than nothing? Absolutely. Is it comparable to an optimized SELinux config? Not remotely.

> This is possible with AppArmor.

See above.

[NewJazz]

You mean the mention of MCS labels? I read that, but I guess I don't understand the practical implications.

[usr1106]

I was surprised by his praise of MCS. We noticed it when reusing the same volume for subsequent reuse of a podman volume. It's a couple of years already, but it was not really explained in the documentation, only in a blog post by a RH emloyee. One weird thing is that the labels are random, but the range of possible values is rather small. So a determined attacker could brute force them. Also we always had a mix of files with and without MCS labels on the volume. IIRC moving or copying files led to different results. Not clear to me why a copy should be protected differently than a moved file, they seem of similar sensitivity to me.

It's been a while and we hacked around it, don't remember how. Except that it was not the #1 solution, disable SELinux altogether.

[IshKebab]

It's not less effective if people actually use it.

[nobody42]

AppArmor is not less restrictive, it's less fine-grained, at the current stage of development at least.