On Wed, Feb 26, 2020, at 10:15 PM, Stephen John Smoogen wrote:
> On Wed, 26 Feb 2020 at 14:06, Jonathan Billings <billings@xxxxxxxxxx> wrote:
>
> > On Feb 26, 2020, at 08:52, Nicolas Kovacs <info@xxxxxxxxxxxxx> wrote:
> > >
> > >> Le 26/02/2020 à 11:51, Nicolas Kovacs a écrit :
> > >> SELinux is preventing /usr/bin/python2.7 from read access on the file
> > disable.
> > >> ***** Plugin catchall (100. confidence) suggests *****
> > >> If you believe that python2.7 should be allowed read access on the
> > disable file by default.
> > >> Then you should report this as a bug.
> > >> You can generate a local policy module to allow this access.
> > >> Do
> > >> allow this access for now by executing:
> > >> # ausearch -c 'f2b/server' --raw | audit2allow -M my-f2bserver
> > >> # semodule -i my-f2bserver.pp
> > >> Weirdly enough, when I follow this suggestion and then empty audit.log
> > and restart my server, I still get the exact same error again.
> > >
> > > I reinstalled this server from scratch and took some notes. This time I
> > was successful, though I don't know exactly what I did differently this
> > time.
> > >
> > > Usually I work as non-root user and call sudo whenever I need root
> > permissions.
> > >
> > > But is this OK when enabling SELinux modules? Let's consider the example
> > given above:
> > >
> > > # ausearch -c 'f2b/server' --raw | audit2allow -M my-f2bserver
> > > # semodule -i my-f2bserver.pp
> > >
> > > Can I also perform it like this?
> > >
> > > $ sudo ausearch -c 'f2b/server' --raw | sudo audit2allow -M my-f2bserver
> > > $ sudo semodule -i my-f2bserver.pp
> > >
> > > I'm not sure with SELinux.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1777562
> > This bug was posted earlier. Sadly, it was closed WONTFIX, but the policy
> > you need is:
> >
> > allow fail2ban_t sysfs_t:file { getattr open read };
> > allow fail2ban_t sysctl_net_t:dir { search };
> > allow fail2ban_t sysctl_net_t:file { getattr open read };
> > Honestly, if this really affects all users of fail2ban, I’ll probably push
> > back on the ticket to get it updated. I’ve successfully had the policy
> > updated to handle issues with popular non-RHEL/CentOS packages.
> >
> >
> So I am thinking that packages are probably going to start having to carry
> around their own policies to fix things like this. Nagios had to start
> doing this a couple of years ago and it might be occurring on all branches.
>
>
I did not get this error on Cent OS 8.
> --
> Stephen J Smoogen.
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
