[olug] SELINUX, you irritate me

Wed Jul 17 18:24:22 CDT 2019

Ok know this one it was probably me 😂.

On Wed, Jul 17, 2019, 1:22 PM Kevin <sharpestmarble at gmail.com> wrote:

> 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
> >
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> https://www.olug.org/mailman/listinfo/olug
>