LWN: Comments on "Disabling SELinux's runtime disable"

AI concern points

farnz — Tue, 02 May 2023 13:57:22 +0000

The trouble is that fails open can also lead to death, as the consequences of people finding out details of medical records includes murder of the patient. So it's not as simple as "fail open == no deaths", because it also results in death.

AI concern points

bartoc — Mon, 01 May 2023 18:39:44 +0000

Are they higher though? In the US the VA has just gone through some horrible trainwreck of a digital records migration and some VA facilities lost access to patient records for a while, I believe it directly caused several deaths. If it fails open then yeah it's a privacy issue but in most cases that can be resolved by making it illegal to access records that you shouldn't have access to and compelling anyone who does to destroy them. Maybe there will be a long and expensive legal process afterwards but nobody will have died.

Disabling SELinux's runtime disable

edeloget — Thu, 27 Apr 2023 12:03:42 +0000

> Aslo, all newcomers, who read docs about fixing odd bugs by whis, will find than older magic no longer works.

Forever lost are the shores of Valinor :)

AI concern points

farnz — Mon, 24 Apr 2023 11:02:45 +0000

The hospital one is actually interesting and complex. You don't want access to patient records that you're not supposed to have access to for a variety of reasons: many countries have laws around patient confidentiality that makes it a career-ending move to look at the wrong set of medical records (GDPR in the EU, HIPAA in the USA, as two examples).

There's thus a tension here; you want access to the records of patients you're actively dealing with, but you also want to avoid having any access to records you should not be looking at, so that you can quickly be ruled out of any investigation into a leak of medical data. And for urgent cases, you don't have time to look at records anyway - you're following a pre-established process for handling the emergency in front of you - and thus don't care if you have access.

So even in the hospital case, you may actually want the system to fail closed, so that you don't have medical records access, since the risks presented by records access are higher than the risk of not having access.

AI concern points

jwarnica — Sun, 23 Apr 2023 00:40:12 +0000

If I worked in a hospital, I'd want access to patient records.

If I worked in a missile silo, I'd want the drives to cook themselves and the armory to unlock.

Disabling SELinux's runtime disable

amarao — Sat, 22 Apr 2023 07:00:50 +0000

Aslo, all newcomers, who read docs about fixing odd bugs by whis, will find than older magic no longer works.

Disabling SELinux's runtime disable

rahulsundaram — Fri, 21 Apr 2023 14:23:53 +0000

> Not speaking for SUSE, but it seems to me that we are switching from AppArmor to SELinux (at least with ALP and MicroOS, I guess Tumbleweed will follow as well..

Interesting. Earlier SUSE explicitly noted this:
https://documentation.suse.com/sles/12-SP4/html/SLES-all/...
"Because many organizations are requesting SELinux to be in the Linux distributions they are using, SUSE is offering support for the SELinux framework in SUSE Linux Enterprise Server. This does not mean that the default installation of SUSE Linux Enterprise Server will switch from AppArmor to SELinux in the near future."

I am assuming the situation has evolved since then.

Disabling SELinux's runtime disable

ceplm — Fri, 21 Apr 2023 12:30:47 +0000

https://www.reddit.com/r/openSUSE/comments/118twi8/why_is...

Not speaking for SUSE, but it seems to me that we are switching from AppArmor to SELinux (at least with ALP and MicroOS, I guess Tumbleweed will follow as well, and the system I write this on is MicroOS with SELinux Enforcing and my office computer is Tumbleweed with SELinux also in the Enforcing mode).

It seems that the last stand of AppArmor is now Debian/Ubuntu. Debian has certainly enough strength to keep it alive, but otherwise there is a long list of Ubuntu-only projects which later died and where replaced by the projects used by the rest of the Linux universe.

AI concern points

Wol — Fri, 21 Apr 2023 11:40:53 +0000

Do you want to fail open, or fail closed?

Cheers,
Wol

AI concern points

jengelh — Fri, 21 Apr 2023 09:25:19 +0000

>any sort of an "off" switch is a potential failure point

One system's off switch is another system's safety switch.

Disabling SELinux's runtime disable

taladar — Fri, 21 Apr 2023 07:48:48 +0000

The thing I personally do not like about SELinux is actually that some distros use SELinux, some use AppArmor, some use neither and if you want to use any sort of config management generated configuration that works on all of them you suddenly have to adjust the pointless differences between distros (e.g. different usernames or paths or config file names) in three or more places (in the actual config and in the policies) instead of just one.

If you forget (or don't know) about adjusting it in one SELinux policy you suddenly have to figure out why your configuration that works perfectly fine on a sane distro doesn't work on "distro that likes to use SELinux but also ancient versions for everything", either because some config option you use isn't supported on that distro or because SELinux blocks it which is often hard to distinguish because the C return code system doesn't give you some proper "blocked by SELinux" error but just some numeric error code that the majority of applications which don't explicitly handle SELinux errors probably logs (if you are lucky) as a generic permission denied or file not found,... error, often without even referencing the operation it tried to perform or the object it tried to perform it on.

Disabling SELinux's runtime disable

nickodell — Thu, 20 Apr 2023 18:40:17 +0000

No, that works by writing to /sys/fs/selinux/enforce.

Disabling SELinux's runtime disable

mattburgess — Thu, 20 Apr 2023 18:12:47 +0000

This is definitely QOTW material:

"I don't understand what I'm doing, I just tinker with things until they work and then I leave well alone and pray they keep working" which is presumably a fine way to be a cleric or a guru, but it's not engineering."

Disabling SELinux's runtime disable

flussence — Thu, 20 Apr 2023 17:39:15 +0000

As the article points out, this is functionally no different to simply not loading a policy. Anyone who has access to early boot to change this setting can also arrange for that to happen in the same place.

The only people this is "hostile" towards are those who are for some reason a) running a system with SELinux they don't have the authority to turn off at boot, b) know enough about the innards of the system to be dangerous, and c) completely, utterly refuse to do even the most rudimentary RTFMing. And after all the BS surrounding systemd, I think people like that have absolutely earned the hostility.

Disabling SELinux's runtime disable

qperret — Thu, 20 Apr 2023 16:08:58 +0000

Moving the function vectors to __ro_after_init could probably be done without disabling the entire feature by using a temporary writable alias (a fixmap?) when modifying them, similar to how e.g. the kernel patches its text. That way the window during which an attacker can use an OOB write (for example) to modify those structs will remain small, making exploitation much less practical. Not being familiar with all the history behind the change, I assume this type of approach has been discussed? Would anyone with enough background be able to share more details as to why this wasn't pursued?

Disabling SELinux's runtime disable

mcon147 — Thu, 20 Apr 2023 15:47:05 +0000

While I can see that some use-cases benefit from this, it seems user-hostile to remove the option

Disabling SELinux's runtime disable

intelfx — Thu, 20 Apr 2023 15:45:52 +0000

> In fact it's often worth going back into systems where somebody was confused and tried turning "off" SELinux to see if that would solve a problem they don't understand, so as to turn it back "on" again now that any problems have been actually fixed.
>
> Like commented out code, disabled/ permissive SELinux settings in production servers are a bad smell. They say "I don't understand what I'm doing, I just tinker with things until they work and then I leave well alone and pray they keep working" which is presumably a fine way to be a cleric or a guru, but it's not engineering.

No contest here. I was just wondering if the enforcement setting and the runtime disable setting were one and the same.

Disabling SELinux's runtime disable

tialaramex — Thu, 20 Apr 2023 15:16:50 +0000

No. You can change the enforcement decision at runtime, and change it back. In fact it's often worth going back into systems where somebody was confused and tried turning "off" SELinux to see if that would solve a problem they don't understand, so as to turn it back "on" again now that any problems have been actually fixed.

Like commented out code, disabled/ permissive SELinux settings in production servers are a bad smell. They say "I don't understand what I'm doing, I just tinker with things until they work and then I leave well alone and pray they keep working" which is presumably a fine way to be a cleric or a guru, but it's not engineering.

Disabling SELinux's runtime disable

intelfx — Thu, 20 Apr 2023 15:00:47 +0000

Is this the same knob that is controlled by `setenforce`?