4 ms·
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 c
by nicce 2y ago
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.
- candiddevmike 2y agoSorry, 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 2y agoI’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 2y agoI'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 2y agoFor 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_Linux_9_v2.0.0_L1_Server.audit:647bbbfd028918a81c7a5281238e1361 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_Linux_9_v2.0.0_L2_Server.audit:acfe5d2a8c034a12a564619db0c03838 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
- generalizations 2y agoYou 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_ 2y agoIts 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/Common_Criteria https://en.wikipedia.org/wiki/Trusted_Solaris https://en.wikipedia.org/wiki/Trusted_Solaris https://en.wikipedia.org/wiki/Security-Enhanced_Linux https://en.wikipedia.org/wiki/Security-Enhanced_Linux
- okasaki 2y agoPoorly designed for general use?
- SubjectToChange 2y agoSecuring Linux, or practically any Unix system for that matter, is like nailing jello to the wall.
- generalizations 2y agoI 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!
- NewJazz 2y agoCan you offer some examples of things you can restrict with SELinux that you wouldn't be able to with AppArmor?
- goneri 2y agoThis is one of the topics of the article.
- vlovich123 2y agoHaving 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.
- deleted 2y ago[deleted]
- ruthmarx 2y ago> 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 2y ago
- rlpb 2y agoA solution that people disable in practice is the least effective solution.
- IshKebab 2y agoIt's not less effective if people actually use it.
- nobody42 2y agoAppArmor is not less restrictive, it's less fine-grained, at the current stage of development at least.