[olug] SELINUX, you irritate me

Justin Reiners justin at hotlinesinc.com
Tue Jul 16 14:58:20 CDT 2019


It's a pain, but I'd rather have it than not.

On Tue, Jul 16, 2019 at 2:44 PM Lou Duchez <lou at paprikash.com> wrote:

> So when SELinux came out ages ago, I quickly developed a strong distaste
> for it.  It felt like it was more likely to do harm than good, like a
> security guard in your building who insists on quarantining your
> groceries to make sure you're not a drug smuggler.  I found I had to
> shut SELinux off to get things to work.
>
> Years later, I am finally conceding that SELINUX is here to stay, and
> it's time to learn to love it (or at least tolerate it).  Here's how I
> finally got on SELinux's side:
>
> 1)    Throw SELinux into "permissive" mode by editing
> /etc/sysconfig/selinux and rebooting.  (If SELinux had been "disabled",
> upon reboot, SELinux is going to have to relabel all the files on your
> system.  This is actually pretty quick, unless you've got directories
> and directories and directories of files.  I had to do this on a couple
> servers that had years of daily snapshots on them, and after a couple
> days the relabeling wasn't done.  I eventually deleted most of the old
> backups -- kept one backup per month, and only since Jan 2018 -- and the
> relabel took under 10 minutes.  Math-wise, I suspect the relabeling does
> not scale linearly with the number of files, but perhaps with the square
> of the number of files.)
>
> 2)    After the reboot, you can run "audit2why -b" and "audit2allow -b"
> to get information on opertaions that SELinux has noted have violated
> policy since booting.  (There are options other than "-b", but I'm just
> talking about how to make SELinux reasonable.  And to me, it's pretty
> reasonable to look at how it's been doing since the last boot.)
>
> 3)    You can run "audit2allow -b -M newrules" to create a file,
> "newrules.pp", that contains SELinux rules necessary to allow all the
> operations that were violating policy.  You can load it by running
> "semodule -i newrules.pp".  You can also look at "newrules.te" to see a
> more visually understandable list of new rules.  Now I won't claim to
> fully understand what the rules are, but I can generally see processes I
> recognize and take it on faith that they're trying to do something
> reasonable.  Like recently I found this entry in newrules.te:
>
>      allow dhcpd_t unlabeled_t:file { append getattr link map open read
> unlink write };
>
> I could do some digging to try to figure out exactly what file it's
> trying to get at.  However, I also know that I've got some custom code
> that creates and overwrites files in /var/lib/dhcpd, so it seems likely
> that SELinux finds my custom code questionable.  Okay SELinux, you win,
> I'll let you have that rule.
>
> 4)    After applying new rules, reboot.  Maybe do another "audit2allow
> -b" to see if anything is still coming up.
>
> 5)    Every few days, see if SELinux is still coming up with messages
> and warnings.  Hopefully you'll reach a  point where SELinux goes for
> days without having any complaints.
>
> 6)    Once you're satisfied that SELinux seems to be pretty happy with
> things, THEN is when you switch SELinux to "enforcing", over in
> /etc/sysconfig/selinux.
>
> All that work to get SELinux properly tuned for your system.  But I ...
> guess it makes things better?  People either love SELinux or hate it
> with a passion, there seems to be no middle ground, and I think I see why.
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> https://www.olug.org/mailman/listinfo/olug
>


More information about the OLUG mailing list