SELinux insanity

[Lonni J Friedman]

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
>
>