SELinux insanity

[Lonni J Friedman]

On Mon, Dec 14, 2020 at 2:11 PM Matthew Carpenter <matt at eisgr.com> wrote:
>
> Hey Lonnie, I hope you'll let this one pass, it's been a while since I've flung
> a distro-war comment:  Perhaps you need to get off RH stuff ;)
>
> jk!  I know that to each their own.  I get enough flack from running Ubuntu.
> RH is a solid choice as well.  Each distros come with their own pain points.
>
>
>
> Anyway, more seriously...
>
> 1) Why do you have *anything* writing random temp files to /etc?

fair point.  but its how fail2ban works on hosts.deny

>
> 2) You can enable permissions by command.  So if you *want* sed to have write
> access to /etc, I guess...
>
> 3) I'm guessing you may want to rewrite whatever tool/script you're using to
> use a real temporary file.

yea, i'm not rewriting or forking fail2ban.

>
> 4) I might consider trying /etc/hosts.deny as a symlink to a different location
> (eg. /var/tmp/shitcan/hosts.deny), where you can give complete access to sed
> without any real concerns.

fail2ban is still going to expect it to be in /etc so it will write
there regardless of what symlink might exist.

>
> SELinux and AppArmor do serve a good purpose.  They *do* stop a lot of
> exploits... and when they don't, they've pushed the attacker to be creative
> and do a lot more work writing their exploit.  Believe me.
>
> I hope you are well, Lonnie.  I miss "hanging out" with you and the rest of
> the gang.  It seems we've all grown up, as has Linux.  Still great to know you
> are still here.
>
> Matt
>
>
> On Monday, December 14, 2020 3:58:29 PM EST Lonni J Friedman via Linux-users
> wrote:
> > The problem is that the file is a sed generated temp file when its
> > editing (note the randomly generated /etc/sedIYn1RO in the error msg),
> > so I have no way of knowing the file name in advance.
> >
> > Thanks for the tip regarding audit2allow.  Unfortunately, its
> > recommending making all of /etc/ writable with:
> >
> > allow fail2ban_t etc_t:dir write;
> >
> > I guess that's better than disabling SELinux altogether, but still kinda
> > crappy.
> > On Mon, Dec 14, 2020 at 12:54 PM James McDonald <james at toggen.com.au> wrote:
> > > I'm reticent to make dumb suggestions as I know you are way more
> > > experienced with this stuff then me but....
> > >
> > > Sounds like you need to change the policy or context of the file you are
> > > doing the in place edit to to allow fail2ban to do it's thing.
> > >
> > > Have you tried audit2allow?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 15 Dec. 2020 7:16 am, Lonni J Friedman via Linux-users
> > > <linux-users at linux-sxs.org> wrote:
> > >
> > > Hi folks,
> > > Hope you're staying safe during these crazy times.  Happy holidays too
> > > (if possible)!
> > >
> > > Remember SELinux?  That thing that Redhat forced upon the (linux)
> > > world so many years ago?  It was supposed to make things more secure.
> > > Its been a thing for such a long time, surely all the rough edges have
> > > been smoothed out by now, right?
> > >
> > > Wrong.  I'm in the process of building out a new production
> > > environment, and I keep tripping over random stuff that doesn't work
> > > because SELinux isn't configured correctly out of the box.  I've
> > > managed to tweak most of the issues, but there's one remaining bit of
> > > SELinux pain that I'm struggling to fix.
> > >
> > > I've got fail2ban configured to manage /etc/hosts.deny for the bots
> > > trying to brute force their way in via ssh.  I don't even permit
> > > password auth, so this is really just to reduce the noise of auth
> > > failures in my logs.  The problem is that SELinux is preventing
> > > fail2ban from calling sed to manage /etc/hosts.deny.  Every time it
> > > tries, it fails with this fun mess:
> > >
> > > 2020-12-13 03:20:32,938 fail2ban.utils          [2312]: ERROR
> > > 7fe1d018cc00 -- exec: IP=$(echo "45.238.121.134" | sed
> > > 's/[][\.]/\\\0/g') && sed -i "/^ALL: $IP$/d" /etc/hosts.deny
> > > 2020-12-13 03:20:32,938 fail2ban.utils          [2312]: ERROR
> > > 7fe1d018cc00 -- stderr: "sed: warning: failed to set default file
> > > creation context to unconfined_u:object_r:net_conf_t:s0: Permission
> > > deniedsed: couldn't open temporary file /etc/sedIYn1RO: Permission
> > > denied"
> > > 2020-12-13 03:20:32,938 fail2ban.utils          [2312]: ERROR
> > > 7fe1d018cc00 -- returned 4
> > > 2020-12-13 03:20:32,938 fail2ban.actions        [2312]: ERROR   Failed
> > > to execute unban jail 'ssh-tcpwrapper' action 'hostsdeny' info
> > > 'ActionInfo({'ip': '45.238.121.134', 'family': 'inet4', 'fid':
> > > <function Actions.ActionInfo.<lambda> at 0x7fe1d06a2b80>,
> > > 'raw-ticket': <function Actions.ActionInfo.<lambda> at
> > > 0x7fe1d06a7280>})': Error unbanning 45.238.121.134
> > >
> > > sed system_u:system_r:fail2ban_t:s0 0 dir write
> > > system_u:object_r:etc_t:s0 denied
> > >
> > > Other than making all of /etc writable, anyone have any suggestions
> > > how to fix this so that fail2ban & sed can do what they need to do?
> > >
> > >
> > > thanks!
> > > _______________________________________________
> > > Linux-users mailing list
> > > Linux-users at linux-sxs.org
> > > http://mailman.celestial.com/mailman/listinfo/linux-users
> >
> > _______________________________________________
> > Linux-users mailing list
> > Linux-users at linux-sxs.org
> > http://mailman.celestial.com/mailman/listinfo/linux-users
>
>
>
>