What exactly is SELinux meant to protect you from?

[leyvi]

What is SELinux meant to protect your system from, and is it overkill for day-to-day use?

[alamahant]

It protects you from daemons ,executables or users accessing resources(files,dirs,ports) that they shouldn't.
Unauthorized access.
Yes it is definitely overkill.
Especially in Gentoo.
The only distro you can use selinux with a desktop as an everyday driver is fedora and redhat derivatives.
In Gentoo you will need to be doing constant troubleshooting and adjustments and end up having a miserable life.
You can always use it in Gentoo in "permissive" mode as a learning experiment but selinux and auditd add an overhead.
Auditd logs massive amount of data.

[leyvi]

Good to know, thanks.

[alamahant]

There is a fantastic package/daemon called setroubleshootd.
This can help you deal with each selinux blocking by suggesting ways to remedy it.
Either by flipping a boolean, or by modifying fcontext or by writting policy.
It tells you this very explicitly, making it easiear to work with selinux.
Gentoo does not offer this package.
This is very unfortunate.

[Zucca]

The only distro you can use selinux with a desktop as an everyday driver is fedora and redhat derivatives.
In Gentoo you will need to be doing constant troubleshooting and adjustments and end up having a miserable life.

In my experience it's also annoying on Fedora and CentOS.

[pietinger]

I hesitated a little before responding here, because one of our Gentoo developers might write a rebuttal. So I'll just go ahead and do it myself:

Probably anyone who knows a little about IT security will say that a server machine should always be equipped with MAC [*]. Here, SELinux is actually mainly used. When it comes to desktops, opinions differ. Some also recommend SELinux here, while others (myself included) consider AppArmor more suitable for a desktop.

*) https://wiki.gentoo.org/wiki/User:Pieti ... protection

What are the benefits of using a MAC system? (see also the link to WikiPedia in my article)

It prevents a program from doing things OTHER than what is actually intended/desired due to a bug in that program.

For example, in 2018, a bug was "built into" OpenSMTPD that allowed users to obtain a shell via OpenSMTPD - Yes, it was a ROOT shell. Anyone using SELinux or AA (and provided they had the appropriate profiles for OpenSMTPD active) was "spared" from this hack... because these systems did not anticipate OpenSMTPD starting a bash... and simply prevented it. The bug was found 1.5 years later in 2020 ... -> https://www.cve.org/CVERecord?id=CVE-2020-7247

For example, I use AppArmor to deny both of my browsers access (not only write access but ALSO read access) to my /home directory. The same would also be possible with SELinux.

[alamahant]

Let me add something.The Selinux provided by the Gentoo developers is way more feature rich and configurable than the "targeted" mode of the redhats.
But with all this power there is potential to really give yourself daily headaches.If you really know what you are doing and are willing to put in the extra work go for it!

[leyvi]

Let me add something.The Selinux provided by the Gentoo developers is way more feature rich and configurable than the "targeted" mode of the redhats.
But with all this power there is potential to really give yourself daily headaches.If you really know what you are doing and are willing to put in the extra work go for it!

Maybe in my homelab

[leyvi]

I hesitated a little before responding here, because one of our Gentoo developers might write a rebuttal. So I'll just go ahead and do it myself:

Probably anyone who knows a little about IT security will say that a server machine should always be equipped with MAC [*]. Here, SELinux is actually mainly used. When it comes to desktops, opinions differ. Some also recommend SELinux here, while others (myself included) consider AppArmor more suitable for a desktop.

*) https://wiki.gentoo.org/wiki/User:Pieti ... protection

What are the benefits of using a MAC system? (see also the link to WikiPedia in my article)

It prevents a program from doing things OTHER than what is actually intended/desired due to a bug in that program.

For example, in 2018, a bug was "built into" OpenSMTPD that allowed users to obtain a shell via OpenSMTPD - Yes, it was a ROOT shell. Anyone using SELinux or AA (and provided they had the appropriate profiles for OpenSMTPD active) was "spared" from this hack... because these systems did not anticipate OpenSMTPD starting a bash... and simply prevented it. The bug was found 1.5 years later in 2020 ... -> https://www.cve.org/CVERecord?id=CVE-2020-7247

For example, I use AppArmor to deny both of my browsers access (not only write access but ALSO read access) to my /home directory. The same would also be possible with SELinux.

I take it AppArmor is a bit less hassle?
The wiki pages on it are pretty short, is there good documentation elsewhere?

[pietinger]

[...] is there good documentation elsewhere?

Unfortunately, the documentation for AppArmor is very limited.

The official wiki is here:
https://gitlab.com/apparmor/apparmor/-/ ... umentation

@ermor has provided a link to OpenSuse documentation here:
https://forums.gentoo.org/viewtopic-p-8 ... ml#8870721

Unfortunately, my own posts have not yet been translated and are in the German section of the forum (all D** threads):
https://forums.gentoo.org/viewforum-f-53.html

[leyvi]

[...] is there good documentation elsewhere?

Unfortunately, the documentation for AppArmor is very limited.

The official wiki is here:
https://gitlab.com/apparmor/apparmor/-/ ... umentation

@ermor has provided a link to OpenSuse documentation here:
https://forums.gentoo.org/viewtopic-p-8 ... ml#8870721

Unfortunately, my own posts have not yet been translated and are in the German section of the forum (all D** threads):
https://forums.gentoo.org/viewforum-f-53.html

German is not an issue for me. Translator programs are quite good these days.

[sublogic]

[...] is there good documentation elsewhere?

Unfortunately, the documentation for AppArmor is very limited.

The archlinux wiki tends to have good writeups. In this case, https://wiki.archlinux.org/title/Apparmor .
I can't tell if this one is any good but it's worth a look. You have to mentally convert any archisms to gentooisms.

[penguinomicon]

An example might help OP. I recently came across a situation where, at the time, it occurred to me that mandatory access control (MAC) might have protected me. It was only a very minor nit, easily addressed in other ways, but it can help get the point across of what MAC does.

I've been playing around with setting up ansible to manage my gentoo systems. For established systems, it means restarting various services with slightly different configurations, since all the special snowflake configs are getting blown away. One of the services I was reconfiguring and restarting was dhcpcd.

Now, on one machine (my daily workstation) I use a local dnsmasq to manage DNS related to my $DAYJOB. Therefore I want resolv.conf to always have nameserver 127.0.0.1 in order to find the local dnsmasq. But, by default, dhcpcd wants to clobber resolv.conf with some other nameservers picked up from the dhcp server. So I ran my ansible playbook and then my work dns broke.

Yes, it was a problem easily identified and fixed (just because I do something dumb occasionally doesn't mean I can't figure it out.) BUT: it did occur to me that this was a classic case where MAC could have automatically blocked dhcpcd from accessing resolv.conf in the first place.

This is the difference between DAC and MAC: protecting resolv.conf only with DAC does mean that I can't, say, clobber resolv.conf just using my regular user permissions. I can't "rm /etc/resolv.conf" without a sudo on the front. MAC, on the other hand, could have had a rule just for dhcpcd: dhcpcd may edit exactly some given list of files only and no others; and then unless resolv.conf were explicitly in the list of permitted files, the MAC would block dhcpcd from breaking my DNS.

Some more of my perspective if you're thinking about experimenting with MAC:

• The MAC implementations I know about (and I assume even the ones I don't) allow you to start in "monitor" mode first, which is like a dry run that shows you what processes are accessing what files. That allows you to begin crafting some rules to show what would be blocked, before you pull the trigger and switch to active blocking. If you're curious, you might as well start doing this immediately to get a feel for what kind of shark-infested waters you're dipping your toes into.
• I've only played with apparmor personally, and I found it fairly approachable, but I have to say I ended up finding it too annoying for regular use on my personal machines. It might be worth it if your IaC is able to roll out well-tested MAC rules to dozens or hundreds of machines in one fell swoop. Then you would know there is a good value multiplier involved in every hour you spend on engineering your MAC. In particular, the annoyance comes from a lot of apps that seem to want to access arbitrary files for obscure reasons and then the apps break when you don't let them access those files. Now multiply this annoyance by the number of apps you regularly run on your system. It might be fine for servers where there should only be specific well-defined types of services running, but it's not fun for an interactive machine like your daily driver.
• SELinux is notorious for being the most complicated MAC. If you're angling towards a job with the NSA, I'm sure they'll still let you in the door if you can say you're familiar with some other MAC first. And if you're not angling towards a job with the NSA, then I'm not sure why you'd even thinking about footgunning yourself quite this hard.

[leyvi]

...
If you're angling towards a job with the NSA, I'm sure they'll still let you in the door if you can say you're familiar with some other MAC first. And if you're not angling towards a job with the NSA, then I'm not sure why you'd even thinking about footgunning yourself quite this hard.

Good to know. I do realize that MAC is rather extreme, but given I already have full disk encryption and secure boot, I thought I might as well...

[leyvi]

I've decided to mess around with AppArmor since YOLO.

Is there a way to run aa-genprof not as root? I don't want to run (for example) my web browser as root.

I guess I could make a group, add myself to it, and set /etc/apparmor.d to be owned by said group, but maybe that's not the best solution?

[pietinger]

I've decided to mess around with AppArmor since YOLO. [...]

Is there a way to run aa-genprof not as root? [...] but maybe that's not the best solution?

TBH I don't suggest aa-genprof ... here is another article about AA ... the chapter "Generating profiles by hand" describes almost the same as I did ...
https://en.opensuse.org/SDB:AppArmor_geeks

[leyvi]

TBH I don't suggest aa-genprof ... here is another article about AA ... the chapter "Generating profiles by hand" describes almost the same as I did ...
https://en.opensuse.org/SDB:AppArmor_geeks

Thanks, that will be very helpful for small tweaks. The thing is, I do actually use this computer for productivity (believe it or not). I'd rather not have to write all that every time I install something. That's why aa-genprof looks so appealing.

[Hu]

Arch Linux has an online copy of the manual for aa-genprof. As I read that manual, you run aa-genprof as root, then it tells you to go manually run the application (presumably as any uid you want). After you tell it you are done, then it generates the profile. Presumably, that means all you need to do is start the to-be-profiled application from a shell running as you. I have not tried any of this.

[leyvi]

Arch Linux has an online copy of the manual for aa-genprof. As I read that manual, you run aa-genprof as root, then it tells you to go manually run the application (presumably as any uid you want). After you tell it you are done, then it generates the profile. Presumably, that means all you need to do is start the to-be-profiled application from a shell running as you. I have not tried any of this.

Thanks Hu, I'll check it out.