SELinux insanity

Matthew Carpenter matt at eisgr.com
Mon Dec 14 14:42:52 PST 2020


fail2ban makes IPTables-updating available.  Perhaps that's a better approach?
Or find another tool?  
This doesn't seem like a SELinux problem as much as a fail2ban problem.  
If fail2ban were a binary app, you could setup rules for it... but since it 
uses sed, you are stuck with enabling sed to write to /etc/

Although, I haven't used SELinux in forever, it's possible the policies allow 
for more granularity than I remember.  AppArmor seems to be somewhat flexible, 
and they use the same underlying kernel subsystem.

Sorry, I haven't had a chance to look much up so I could be of real value.

Matt

On Monday, December 14, 2020 5:16:41 PM EST Lonni J Friedman wrote:
> 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






More information about the Linux-users mailing list