Hi,
Some time ago I had SELinux problems with Fail2ban. One of the users on this list suggested that it might be due to the fact that I'm using a bone-headed iptables script instead of FirewallD.
I've spent the past few weeks getting up to date with doing things in a more orthodox manner. So currently my internet-facing CentOS server has a nicely configured NetworkManager, and FirewallD has replaced the iptables script.
Unfortunately when I install FirewallD from EPEL, I still get the same error.
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.
Which makes Fail2ban unusable with SELinux in enforcing mode in the current state.
Any suggestions ?
Niki
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.
Cheers,
Niki
On Feb 26, 2020, at 08:52, Nicolas Kovacs info@microlinux.fr 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.
-- Jonathan Billings
On Wed, 26 Feb 2020 at 14:06, Jonathan Billings billings@negate.org wrote:
On Feb 26, 2020, at 08:52, Nicolas Kovacs info@microlinux.fr 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.
On Wed, Feb 26, 2020, at 10:15 PM, Stephen John Smoogen wrote:
On Wed, 26 Feb 2020 at 14:06, Jonathan Billings billings@negate.org wrote:
On Feb 26, 2020, at 08:52, Nicolas Kovacs info@microlinux.fr 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@centos.org https://lists.centos.org/mailman/listinfo/centos
On 2/26/20 12:15 PM, Stephen John Smoogen wrote:
On Wed, 26 Feb 2020 at 14:06, Jonathan Billings billings@negate.org wrote:
On Feb 26, 2020, at 08:52, Nicolas Kovacs info@microlinux.fr 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.
This is certainly the plan for fail2ban - but the bundled SELinux packaging guidelines currently make use of conditional dependencies so that's not going to fly for EL7. And unfortunately since RHEL7 is in maintenance the selinux-policy package isn't going to be updated either.
On 2/26/20 9:52 AM, Nicolas Kovacs 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
This should work. Likely the reason that it didn't resolve in one go is that there were multiple denials - but the first time it just failed on the first one. Someone else mentioned running in non-enforcing mode to allow the audit log to collect all of the denials and then generating the module - this is a good practice.
On Wed, 26 Feb 2020, Nicolas Kovacs wrote:
Some time ago I had SELinux problems with Fail2ban.
Unfortunately when I install [...] from EPEL, I still get the same error.
EPEL packages are often crap quality (as packages), merely blind imports of the upstream package without any adjustments needed for the RHEL/CentOS environment (sometimes not even for Fedora), which is often somewhat different than the Fedora environment which go unnoticed or unrepaired, for years.
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.
Have you reported it? To the Fail2Ban EPEL package maintainer, not to the (upstream) Fail2Ban maintainers, nor the CentOS (thus RHEL) Python package maintainer, nor the Python maintainers, i.e., the issue is that the EPEL Fail2Ban package does not (seem to, based on your message) have the correct RHEL/CentOS SELinux definitions.
You can generate a local policy module to allow this access.
Weirdly enough, when I follow this suggestion and then empty audit.log and restart my server, I still get the exact same error again.
This sometimes needs multiple iterations to catch all the types of access attempted, e.g., initially it might be that read is denied, but later the process would want other permissions like write but which were never logged because of the initial read failure.
Any suggestions ?
Try repeating. That either means multiple binary modules, or a text module that you add each new audit2allow "fix", increment the version number, rebuild the policy and module then re-insert -- lather, rinse, ...
/mark
On Thu, 2020-02-27 at 02:49 -0800, Mark Milhollan wrote:
On Wed, 26 Feb 2020, Nicolas Kovacs wrote:
Some time ago I had SELinux problems with Fail2ban. Unfortunately when I install [...] from EPEL, I still get the same error.
EPEL packages are often crap quality (as packages), merely blind imports of the upstream package without any adjustments needed for the RHEL/CentOS environment (sometimes not even for Fedora), which is often somewhat different than the Fedora environment which go unnoticed or unrepaired, for years.
This sounds a bit harsh. But I had my problems with fail2ban too.
This sometimes needs multiple iterations to catch all the types of access attempted, e.g., initially it might be that read is denied, but later the process would want other permissions like write but which were never logged because of the initial read failure.
Any suggestions ?
Try repeating. That either means multiple binary modules, or a text module that you add each new audit2allow "fix", increment the version number, rebuild the policy and module then re-insert -- lather, rinse, ...
A better way is to put selinux in permissive mode and then generate the policy from the alerts. This will disable the blocking so you can get all issues in one go
/Louis
-
Benson Muite -
Jonathan Billings -
Louis Lagendijk -
Mark Milhollan -
Nicolas Kovacs -
Orion Poplawski -
Stephen John Smoogen