[semiquaver]

FWIW, I’ve worked at many RedHat shops over the years and I’ve never seen one where disabling SELinux wasn’t a normal part of provisioning a server. I haven’t seen the same thing with AppArmor (although I admit I have less visibility into debian systems administration). YMMV but it seems to me that a component which is so inconvenient that it’s normally disabled doesn’t provide much security in the end.

[darkwater]

Security folks usually are detached from the actual reality, unfortunately.

Yes, people/sysadmins should take their time to properly configure SELinux when things don't work, instead of just disabling it completely for good. I tried for a whole year in a place where we used CentOS, and then finally I gave up, too many hours wasted in finding the right conf for this new program or configurations etc.

[Spivak]

I feel like I'm taking crazy pills in this thread. SELinux is so easy to set up in anything RHEL 7+. Everything from the distro works ootb, the auditor will tell you exactly what caused the error, it will give you the commands to fix it, and you can label programs you don't want to deal with with unconfined_t. There's no reason to completely disable it, you lose all the benefit of all the software Red Hat engineers have already made work with it.

[generalizations]

Have you ever read the commands the auditor gives you? They can be laughably broad, barely short of just giving the app unconfined permissions. If you're just blindly copy-pasting what it tells you, you might as well just disable it.

[Spivak]

Yeah, they're not great recommendations sometimes but they do have the advantage of always allowing the behavior which I think is meant to not make a frustrated ops person even more mad. But I disagree on the "you might as well disable it" because now you've lost the policies on the thousands of packages you didn't make exceptions for. Even if $company_app is running basically unconfined at least sshd is still locked down.

[jabroni_salad]

coming from the IT Operations side of things, most developers who I work with are unable to tell you how to get their application through a dead simple stateful firewall much less any kind of OS-level control scheme like selinux or applocker.

Watching a 15 minute selinux tutorial video will give you a moat ahead of 90% of the community but it won't matter because management kind of agrees that anything that slows you down has to go, and security policy is ultimately just a type of insurance rather than a revenue generating activity. Disabling selinux reduces cost today so we might as well go for it.

I do think it is worth having on any public webserver since it's only a matter of time before your app gets popped and you want that sucker in jail, but I gave up on internal servers a long time ago.

[xorcist]

As an ops person, is it not your profession to make applications work in the real world with firewalls, load balancing, certificates, and mandatory access control? I have never worked somewhere where that wasn't part of the sysadmin/ops/SRE/devops role. Where devs do it, it's only because you're small enough to lack the specialists.

[Conan_Kudo]

Yeah, when I was an infrastructure engineer, this was definitely part of the work I was expected to do, though eventually I turned it into educating and supporting developers in understanding security technologies and leveraging them for their application development. But that's just because I wanted to do it that way.

[kjs3]

most developers who I work with are unable to tell you how to get their application through a dead simple stateful firewall

What sort of disaster area do you work in where it's the developers job to tell security ops how firewalls work?

[StressedDev]

Typically, developers have to tell the operations/sys admin/devops people a lot of things to get their application running in test/pre-production and production. Here are some examples:

- Network ports the service listens on - What security permissions does the application need - What commands have to be run so the application starts - What platform does the service use? Java, Node, C#, C/C++, Go, something else? - What GIT repository or repositories contains the service's code? - How does the build work? - What needs to deployed to the machine? - Any configuration changes the application needs

There are also a lot of join decisions where the operations engineer and the software engineers have to work together. Here are some examples: - What cloud will the team use? (AWS, Azure, GCE, etc.)? - What cloud technologies will the team use? - What database will the team use? - How will logs and alerts work? - How will the on-call rotation work?

My main point is you cannot just tell an operations person to deploy something and expect good results. They will have a lot of reasonable questions and software engineers should be able to answer them.

[jabroni_salad]

When we onboard, say, M365, they provide a list of 50 or so URLs that we can expect their service to use. Sure we could get the common ones out of the way on our own but 3 months from now someone is going to click a weird button that deeplinks to some oddball one-off domain that they had lying around for some reason. It's nice of microsoft to let us know all the URLs they are associated with in advance.

Is there any reason that you do not know what your application can be expected to connect to? You wrote the thing, right?

I work with a lot of external vendors who offer self-hosted software and a really common refrain is "it must be a network problem" but these guys are universally unable to describe their application's networking requirements.

[DyslexicAtheist]

"tell me what outgoing ports the application needs" is what results in blank stares the most. its embarrassingly basic, but maybe it has something to do with "senior" devs only being on the job for mere 5-8 years. that is the amount of time good cybersec people spend on understanding security after a decade in dev (or in ops).

[rescbr]

Ohh! I’ve been at the other side of this discussion.

It usually goes like:

“What are the outgoing ports?” “1024-65535, I mean, the app is using X language’s standard library to make an HTTPS request.”

“What are the IPs we have to whitelist?” “You can either allow app.example.com or take AWS’s IP range JSON file and allow all of those, we don’t control what IP gets assigned to AWS’s API Gateway service”

Then some cloud provider’s SA/SE gets looped in to say the same stuff to the security team.

Some exec then gets escalated and approves this as a risk.

Tale as old as time.

[AnonCoward42]

I keep SELinux enabled at all times, but it does break quite often. For the sake of sticking to Fedora, wg-quick (wireguard) does not work out of the box.

On OpenSUSE/MicroOS who is employing SELinux boot takes about 5 minutes on every kernel change, because of home-relabel. I hear you, that they probably do it wrong, but that's what you get with SELinux. Not enough to push me to disable SELinux, but maybe to avoid SELinux distributions in the future.

[OSI-Auflauf]

I use wg-quick via the parameterized systemd unit (wg-quick@.service) all the time and never had selinux blocks. Which fedora are you on?

[AnonCoward42]

Fedora Silverblue 40 (updated)

[drewlander]

I agree. I have worked at various companies that use Red Hat/CentOS extensively and the only time I ever saw someone turn Selinux off was on RHEL 6. Ever since then, it has been easier and easier to use. Not saying it is perfect for everyone, but it does work and can be made to work well.

[IshKebab]

You must have been extremely lucky because I've had multiple apps just trigger endless SELinux warnings on RHEL8 (Rustdesk is an example) and I very much subscribe to the views in this article:

https://www.ctrl.blog/entry/selinux-unmanageable.html

I'm not going to waste my time fighting SELinux to stop non-existent threats (I'm just using a desktop and I'm not a high profile target). Too many false positives and I'll just turn it off. And in my experience there are always too many false positives.

[aarmenaa]

The documentation is atrocious, and usually won't say things like "label your program unconfined_t" because they don't want you to do that ever. Also, tutorials -- even RedHat's -- are always some variation of "here's how to use audit2allow." That is very much not what I want. I want to create a reusable policy that I can apply to many hosts via Ansible or as part of an RPM package I created. I've never been able to figure out how to do that because it is always drowned out by SEO spam that barely scratches the surface of practical usage.

It's painfully obvious to me that the people who create SELinux and its documentation live in some alternate universe where they don't do anything the way I do, so I just turn it off.

[KAMSPioneer]

Not excusing that state of documentation by any means, but a good starting point for understanding the actual policy for me was "SELinux System Administration" (ISBN 978-1-80020-147-7).

It won't carry you all the way to applying policies via Ansible or RPM packages, but definitely took me from running random audit2allow commands to taking a more holistic view of my SELinux policies.

It also looks like a long read but if you fast-forward through chapters that aren't relevant to you (looking at you IPSEC) it isn't such a slog.

[darkwater]

(this was in 2016) Yes, usually the logs pointed you in the right direction, but it still made things more complicated and trick the "lazy attitude" in many people (or, at least, in me).

[bvrmn]

I maintained policies for multiple proprietary products. It took several months to get a grasp how SELinux works and what it wants from me. It's quite far from easy.

> it will give you the commands to fix it

Usually it's a crap you should not apply to the system.

[SAI_Peregrinus]

The "CIA triad" definition of security (Confidentiality, Integrity, and Availability ) is most often violated by loss of the Availability component. Very often by "security" mechanisms that effectively serve as a Denial of Service attack on the users.

A system which is easy to use securely will stay secure, a system which is difficult to use securely will be insecure.

[EvanAnderson]

I always pushed back hard on vendors who wanted me to disable SELinux on my RHEL boxes. It's unacceptable to disable default OS security protections to make an application function. It's no different than demanding an app run as root.

[stevekemp]

Indeed, disabling SELinux is like following instructions for PHP applications and running "chmod -R 777 /var/www".

I used to work at a payment provider and we had to deal with lots of monitoring and security stuff. Some of it was (obviously) busywork and needless checkbox filing, but other parts were genuinely useful. Setting up systems was tedious and difficult, but ultimately worthwhile and necessary.

[bigfatkitten]

> Indeed, disabling SELinux is like following instructions for PHP applications and running "chmod -R 777 /var/www".

HP at one point said to "chmod -R 777 /sbin" in their ArcSight install documentation, and that's a 'security' product.

[01HNNWZ0MV43FF]

Oops

-- A developer whose app needs to run as root (for a well-documented reason, and with a tight systemd sandbox hiding most of the filesystem from it)

[NewJazz]

If it is running as root, can't it just manipulate its mount namespace at will? Mount devtmpfs, then mount user partitions.

[hackernudes]

I believe one can use "capabilities" and seccomp to lock down a superuser process.

[superb_dev]

Systemd can put it in its own namespaces, like a container

[kbolino]

It's worse, actually. Root can still be confined under SELinux with a good policy.

[giancarlostoro]

This reminds me of my college years and the one time we used Fedora and someone accidentally set it up with SELinux, we spent hours pulling our hairs out trying to figure out why nothing worked. Only to finally realize SELinux was the culprit and we needed to turn it off.

[mhitza]

SELinux has been enabled on Fedora for as long as I remember.

SELinux is complex, badly documented, policy code is obscure macro incantation, and basic debugging tools often aren't installed out of the box on server distros (such as audit2allow). But for the day to day administration of systems, policies are included for distribution packages and most issues can be fixed by enabling a boolean here and there, and relabeling files.

The principles, basic admin & debugging part can be learned in a couple of hours, and when you have custom service software, you can throw it in /opt and have it run unconfined (ie: not subject to SELinux rules).

[jerf]

"The principles, basic admin & debugging part can be learned in a couple of hours,"

In principle, yes. In reality I've gone looking for a resource that I could do this with and come up short.

(I am starting to get really annoyed at things where I can find a million "paste this bit to do that thing" and there are so darned many of those on the internet that any hope of finding a good resource that gets to the underlying structure such that I can figure out how to do these things myself is virtually nil. It seems like this is getting worse as the search engines continue their trend of taking your query as a vague suggestion of the sort of thing you're looking for.)

[mhitza]

Maybe I'll write that guide, and then (fingers crossed) people will find it via search engines (before all search engines become just an LLM frontend).

[jerf]

Well, if you do, my email is in my profile and I'll be happy to be an advance proofreader if you're interested. I've got a couple of teens in a very similar position as well, so I can even provide multiple people's point of view. I have pretty much the exact right amount of experience for that; I've been in there, I've done things, even completed a couple of non-trivial projects (nothing amazing, but, more than just "a pad with a pocket in it"), I recognize I'm confused, I don't know where to proceed from there.

[jerf]

Scratch this, this was in error. It referred to a version of the post I never posted and I got myself confused.

[KAMSPioneer]

I mentioned elsewhere in the thread, I (well, my employer) picked up a copy of a book on SELinux System Administration (that's the title) and it has served just this function for me.

It won't make you an expert but it takes the voodoo out of the whole process, if that makes sense. And it is reasonably short if you skip the stuff that you're (probably) never going to configure like passing labelled traffic between hosts with IPSEC.

[XorNot]

It's baffling to me that SELinux's UI is like...the best we can apparently do?

The underlying concepts of SELinux aren't so hard but trying to manage it in any sort of coherent way is a nightmare - up to and including the provisions in it for a network based policy server component which just never appeared.

And it sucks! In theory it does so many things we really really want, and should do more. Like I as a user have a great interest in ensuring my home directory files follow sensible markings based on their content - my SSH keys, AWS keys, or banking files all exist in different logical zones of control.

And this is a concept SELinux can handle...but the tools are just so bad at surfacing it.

[mike_hearn]

It's not. The (undocumented!) SBPL that Apple OS' use is easier to understand and debug than selinux, in my experience.

[giancarlostoro]

Reminds me of git itself, you read about its internals it sounds easy. You start trying to figure out how to map commands in a way that makes sense, it baffles you when things break.

[TheRealPomax]

Why would the NSA want to make something easy to use for others?

[Gud]

Why wouldn't they?

[gizmo686]

Because that's not their job. The NSA sponsored the development of SELinux because they needed something to solve their problems. The current state of SELinux does that. Why would they spend resources solving problems that they don't have.

[TheRealPomax]

Kind of a weird counter-question? Why would any business spend more effort on building a tool than is necessary to make the tool they need? The NSA doesn't care about brownie points.

[throwaway894345]

I haven’t touched SELinux. How does it compare to Systemd (presently my standard for “ubiquitous despite terrible UX”).

[goneri]

Disabling SELinux is pretty much like doing a chmod -R 777 ., it may fix your "problem", but it's certainly not the long term solution.

[area51org]

I wouldn't say it's that drastic. Also, SELinux can give you a false sense of security. It's best to harden the system overall instead of relying on one security feature (however good it might be).

[Spivak]

Yes, and SELinux is by far the most powerful tool that exists for hardening your system overall. Why would you skip it?

[speckx]

This has worked for me in the past, but it's not something anyone should do in production. ;)

Then again, Disabling SELinux is necessary. For example, cPanel requires disabling SELinux on CentOS, AlmaLinux OS, CloudLinux, and Rocky Linux. AppArmor is fine on Ubuntu (https://docs.cpanel.net/installation-guide/system-requiremen...).

[rurban]

It's not necessary, it's a stupid dick move. cPanel was just not capable to tune the selinux profiles for their services, I've worked there.

My servers all run with selinux, it's really trivial. Just the ssh client and tailscale recipes are missing by default. Selinux gives you precise choices if something is rejected.

[ThatMedicIsASpy]

I've had no issues for personal use. Be it Fedora or Fedora Server. When I ran into issues the logs often come with a solution.

[candiddevmike]

IMO, it's because relying on filesystem labels and compiled policies (SELinux) ended up being a poor design choice vs defining the access in easy to understand policy files (AppArmor).

[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.

[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]

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.

[kbolino]

At least as far as the filesystem labels are concerned, the designers of SELinux consciously chose to use inode-based labels instead of path-based policies because the latter can be dodged via hard links. For this reason, it's best to disallow hard linking when using AppArmor, while such a restriction is unnecessary under SELinux.

[cvhc]

I just feel SELinux would add too much burden to sysadmins. I use CentOS + SELinux in one of my VPS and it's already painful. I've been sysadmin in university labs for some years. I did what I think is reasonable, setup a firewall, limit root access, never trust lab servers to the extent that I forward my SSH agent on it... But I don't want users come to me every time they want to run a custom / proprietary program and I spend time writing and debugging MAC rules.

And I don't agree with the article that containers do not add security. Container runtime implements namespace isolation, seccomp filters, etc. and that reduce the attack surface, comparing to running the software directly on the host OS. More importantly in this discussion, it is convenient for sysadmins.

There is no perfect security anyway. And I don't sacrifice convenience for national security level security :)

[Go7aiTha]

The k8s nodes in Oracle system are shipped with SELinux (permissive mode). One of the those nodes was extremely slow and we found out it's due to SELinux . We have to completely turn SELinux off, reboot the machine, and well, our pod start time reduced from 5 minutes to a few seconds.

[dspillett]

That much difference in boot time with no other changes would suggest to me something (or multiple somethings) calling out in a way blocked by SELinux, and timing out rather than failing quickly. You might want to check that you don't have any undesirable calling home going on from some of your containers.

[bluedino]

Exact opposite here, all the RHEL shops I've worked at were required to have SELinux for industry/security regulations.

Most of the places who used CentOS for a 'free' Linux ended up shutting it off, though.

[mst]

Rule 777: If you make a system secure but difficult to use, your users will find a way to make it easy to use but insecure.

[turtle_heck]

Every RHEL server we ever provisioned (dev, testing, prod, vm, physical, etc) had it enabled, everyone who blindly disables it is lazy.

[WhyNotHugo]

I think the article summarises the situation well:

> The policy language and tooling is cumbersome, obtuse, and is about as appealing as filling out tax forms.

If a security framework is so terribly complex and hard to use, then people won’t use it.

OTOH, look at how OpenBSD or OpenSSH approach security: simply primitives which are well documented and easy to understand.

The only reason SELinux even works in the few scenarios where it does, is because the operator had immense amount of resources to pour into it. This itself is another sign of how bad the design is: it’s so complex that no small team of humans have ever been able to use it.

[citrin_ru]

SELinux is pain to maintain in more or less complex system. I more like approach taken by OpenBSD [1] but it requires code changes.

[1] https://man.openbsd.org/pledge.2

[mrweasel]

Pledge and Unveil makes a ton of sense, because it moves the responsibility to the developer who should know the application better than the systems administrator.

Sometimes, when the developers make a mistake, which is unavoidable in a large project, it is nice to be able lock down applications as the administrator.I just don't think SELinux is the right tool, because the chance of you making a mistake in the configuration is pretty high. The functionality is there, but it needs to be easier to write policies and maybe that comes at the cost of some flexibility.

[nequo]

> the developer who should know the application better than the systems administrator

On the other hand, the administrator knows their system better than the developer. There could be certain network connections or file paths that you want to block on one system but not on another.

[ruthmarx]

The OpenBSD approach isn't even in the same league. Not only it is developer opt-in, but it is also limited to enforcing or restricting syscalls, that's it. If you have a root RCE in say sshd, pledge won't help you. SELinux will.

[minkles]

I never turned off SELinux. There are a few of us out there!

[NewJazz]

The infra team at my work is now keeping it on for new EL9 installs due to pressure from the security team, but for the past 10-15 years they kept it disabled.

I'm hoping it sticks. Just check audit logs when you get an error, it is not that hard, right?

[pjmlp]

All the people using Android phones as well.

[ruthmarx]

> I’ve never seen one where disabling SELinux wasn’t a normal part of provisioning a server.

These days that's just laziness/fear, and it's a shame to see it. It doesn't even make sense any more.

[CrLf]

SELinux suffers from a reputation problem. It gained that reputation early on, while default policies were still very immature and overly restrictive.

One crucial change for the better was leaving third-party software in a permissive state. From that point onwards, disabling SELinux is cargo-cult sysadmin'ing.

SELinux is not hard if you understand its basic principles. But no one bothers, because SELinux is the bogeyman.

Yes, writing policies means getting knee-deep in macros, and it's hard because many services try to access anything and everything. But almost no one needs to write a policy.

At most you need to tell SELinux that some non-default directory should have some label. That's not hard.

[noinsight]

> But almost no one needs to write a policy.

But that's exactly what I would like to do! I've never seen a real guide for how to set up a policy for a custom daemon I wrote myself. Or when a specific software doesn't come with a policy.

[CrLf]

It's true that there is a lack of simplified documentation. But that lack is also the result of the folks that would otherwise contribute to such documentation not even giving SELinux a chance.

Many years ago I decided to face the Bogeyman and went from knowing very little about SELinux to writing a policy from scratch in about a month. The policy is simple enough (but realistic) that it might help in the absence of a guide:

https://github.com/carlosefr/kyoto/tree/master/selinux

I used it as an example in a couple of talks, whose slides might also provide additional context:

https://github.com/carlosefr/public-talks/blob/master/presen...

[cesarb]

> At most you need to tell SELinux that some non-default directory should have some label. That's not hard.

In my experience, it's not just directory labels ("semanage fcontext -a -e ..." and friends). You also need once in a while to set some booleans ("semanage boolean ..."). Yes, it's not hard once you know about it.

[nineteen999]

When you are working in an industry where peoples lives are at stake, then it matters. It matters less if your business is just selling internet-widgets or what not.

We don't disable SELinux.

[master_crab]

This. Disabling Was always the first step when we used RHEL years ago.

SEL seems to work under the premise that if it’s too complicated for you to use, the attacker has no chance.

[redprince]

Because pretty much everyone on the internet tells you to disable SELinux instead of trying to understand it. I'm always rolling my eyes when I open some deployment instruction for RHEL (clones) and they have as step one: Disable SELinux.

Few will instead read the RHEL provided documentation. Then they could maybe figure out whether there's simply a tunable (getsebool -a) which would enable the desired behavior, or if properly labeling files (semanage fcontext / restorecon) would do it, or even take the steps to add to an existing policy to allow for a specific scenario which somehow was not implemented. Even adding your own policies "from scratch" is certainly doable and provides a great safety net especially for networked applications.

Anyway... we all know disabling security or not implementing it in the first place can really save you a lot of time. At least in the short run.

[epalm]

> Anyway... we all know disabling security or not implementing it in the first place can really save you a lot of time. At least in the short run.

The way I put it to my clients, and staff, is simply that security comes at the cost of convenience.

[wwweston]

Are there good places to read more about this?

[redprince]

If you just want to maintain or operate what's already there on a RHEL (clone): https://docs.redhat.com/en/documentation/red_hat_enterprise_...

If you want to dive deeper: "SELinux System Administration" by Sven Vermeulen.

[mananaysiempre]

A book published by Packt? Really? Honest question, it’s just that so far I haven’t noticed them having much of a quality filter or an editing team.

[jklinger410]

> I’ve never seen one where disabling SELinux wasn’t a normal part of provisioning a server

This is so funny because whenever I suggest Fedora Silverblue to a moderately experienced Linux user who wants a simple distro, the first thing I do is recommend turning SELinux on permissive mode, and I get a bunch of comments hand wringing about how you shouldn't do that.

It's almost like a silent filter working in the background of your OS that doesn't even tell you when it blocks something is a pretty user hostile feature and no one wants to learn how to speak SELinux so they can effectively use it.

Sometimes it seems like Linux people don't want others using it. Even when they belong to evangelist platforms, they like to create huge barriers for entry and then blame new users for not "getting it."

[m4rtink]

I think all the SELinux denials are logged in Journal and there are good tools to analyze them and possibly turn them to rule changes if necessary.

[nobody42]

It's a symptom. Seems that label-based MAC is too tightly coupled with other parts of the system. With path-based, there's no need to disable it (entirely) because each part have their own separated strict scope.

[bravetraveler]

Well, the comparison is flawed. Apparmor does nothing for applications not explicitly enabled or enrolled

SELinux does better or worse, depending on perspective, by actually enforcing controls

[quasarj]

Thank you.. came here to say exactly this. Who the heck is using SELinux? hah

[commandersaki]

Hah, came here to say this as well.