[olug] SELINUX, you irritate me

[Kevin]

No, what you do is to use iptables to block 22, then redirect tcp/12345(or
so) to port 22. Then, 6 months later, you find you can't SSH to your
server, figure out that you need to SSH to tcp/12345 instead of tcp/22 and
wonder what moron set it up that way.

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

> Yeah.  The trick is tuning it before activating it, rather than
> immediately activating it and then all aitch-eee-ell-ell breaks loose.
>
> One thing SELinux does to earn my immediate ire is, first thing I do
> when I configure a new Linux server is switch SSH to a nondefault port.
> SELinux thwarts that every time, and that goes a long way to making me
> irrationally angry at SELinux.  There's a perfectly simple response to
> that -- throw SELinux into "permissive" mode and then do the audit2allow
> steps as outlined below (which will fix the SSH port thing) -- but
> SELinux does not really endear itself to me by making it harder to
> implement sensible security choices.
>
> But that just means it's up to me to meet SELinux halfway.  Well, 99% of
> the way.
>
>
> > 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
> >>
> > _______________________________________________
> > OLUG mailing list
> > OLUG at olug.org
> > https://www.olug.org/mailman/listinfo/olug
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> https://www.olug.org/mailman/listinfo/olug
>