SELinux insanity

Matthew Carpenter matt at eisgr.com
Mon Dec 14 14:11:05 PST 2020


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?

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.

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.

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