similar to: SpamAssassin vs. SELinux

Hi, I'm running CentOS 7 on an Internet-facing server. SELinux is in permissive mode for debugging. I've removed FirewallD and replaced it with a custom-made Iptables script. I've also installed and configured Fail2ban (fail2ban-server package) to protect the server from brute force attacks. Out of the box, Fail2ban doesn't seem to play well with SELinux. Here's what I

Hi, I've setup a transparent HTTP+HTTPS proxy on my server running CentOS 7, using Squid. Here's my configuration file. --8<---------------------------------------------------------------- # /etc/squid/squid.conf # D?finitions acl localnet src 192.168.2.0/24 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port

Hi, Spamassassin has been working nicely on my main server running CentOS 7 and Postfix. SELinux is activated (Enforcing). Since the most recent update (don't know if it's related to it though) I'm getting the following SELinux error. --8<----------------------------------------------------------------- SELinux is preventing /usr/bin/perl from 'read, write' accesses on

On Feb 26, 2020, at 08:52, Nicolas Kovacs <info at 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.

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

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

On Wed, 26 Feb 2020 at 14:06, Jonathan Billings <billings at negate.org> wrote: > On Feb 26, 2020, at 08:52, Nicolas Kovacs <info at 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)

Hi Leon, I don't have access to a CentOS 6.10 system handy, but it looks like a policy issue. If I take you're ausearch output and pipe it to audit2allow on my CentOS 7.6 system, I get the following: #============= httpd_t ============== #!!!! This avc is allowed in the current policy allow httpd_t httpd_sys_script_t:process signull; Noting that on my 7.6 system with selinux enforcing

On 03/09/2018 05:18 AM, Nicolas Kovacs wrote: > Do allow this > access for now by executing: > # ausearch -c 'ssl_crtd' --raw | audit2allow -M my-sslcrtd > # semodule -i my-sslcrtd.pp > > Unfortunately the suggested solution doesn't work Start by running "ausearch -c 'ssl_crtd' --raw" by itself.? Try to determine whether or not all of the affected

On Thursday, August 21, 2014 12:00:03 centos-request at centos.org wrote: > Re: [CentOS] SELinux vs. logwatch and virsh > From: Daniel J Walsh <dwalsh at redhat.com> > To: CentOS mailing list <centos at centos.org> > > On 08/18/2014 02:13 PM, Bill Gee wrote: > > Hi Dan - > > > > "ausearch -m avc -ts recent" produces no output. If I run it

Hello List, after the last update I have a selinux "Problem" with dovecot. My system is a centos 7. After a new start from dovecot selinux block a connection. Jul 12 16:24:24 mx01 systemd: Starting Dovecot IMAP/POP3 email server... Jul 12 16:24:54 mx01 systemd: Started Dovecot IMAP/POP3 email server. Jul 12 16:24:54 mx01 dovecot: Warning: Corrected permissions for login directory

Mark: Labels look OK, restorecon has nothing to do, and: -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /bin/ps dr-xr-xr-x. root root system_u:object_r:proc_t:s0 /proc I'll send the audit log on to Dan. Cheers, John On 2 December 2014 at 16:10, Daniel J Walsh <dwalsh at redhat.com> wrote: > Could you send me a copy of your audit.log. > > You should not be

Indeed, thanks Dan - it doesn't get us to a completely clean running that would allow us to run our Node app as we are under Passenger with SELinux enforcing, but it at least has stopped the excessive amount of AVCs we were getting. John On 3 December 2014 at 10:01, Daniel J Walsh <dwalsh at redhat.com> wrote: > Looks like turning on three booleans will solve most of the problem.

Daniel Walsh wrote: > On 09/22/2017 06:58 AM, hw wrote: >> >> PS: Now I found this: >> >> >> type=PROCTITLE msg=audit(09/22/2017 12:08:29.911:1023) : proctitle=/usr/lib/sendmail -t -oi -oem -fwawi-genimp >> type=SYSCALL msg=audit(09/22/2017 12:08:29.911:1023) : arch=x86_64 syscall=setgroups success=no exit=EPERM(Operation not permitted) a0=0x1

I updated my backup server to CentOS 6.6 this morning. As usual, I unmounted the current (nightly) tape from the changer before the reboot. Now Bacula complains it cannot access the changer: 3301 Issuing autochanger "loaded? drive 0" command. 3991 Bad autochanger "loaded? drive 0" command: ERR=Child exited with code 1. Results=cannot open SCSI device '/dev/changer' -

I'll jump in here to say we'll try your suggestion, but I guess what's not been mentioned is that we get the setroubleshoot abrt's only a few times a day, but we're getting 10000s of setroubleshoot messages in /var/log/messages a day. e.g. Dec 2 10:03:55 server audispd: queue is full - dropping event Dec 2 10:04:00 server audispd: last message repeated 199 times Dec 2

Applied policy update. Now I see these occasionally. But by the time I try and see what the matter is the file is gone: /var/log/maillog . . . Dec 9 15:12:08 inet08 postfix/smtp[3670]: fatal: shared lock active/0A7EC60D8A: Resource temporarily unavailable . . . Dec 9 15:12:08 inet08 postfix/smtp[3758]: fatal: shared lock active/8DD5060F81: Resource temporarily unavailable . . . Dec 9 15:12:09

Le 23/05/2018 ? 16:58, m.roth at 5-cent.us a ?crit?: > A suggestion: once you've got the firewall issue dealt with, set selinux > into permissive mode; *then* you can figure out what it's complaining > about, while at the same time, your system will be available. Once you've > fixed those issues, then you can make it enforcing. This is always my approach. Turns out the

CentOS-6.6 Postfix-2.11.1 (local) ClamAV-0.98.5 (epel) Amavisd-new-2.9.1 (epel) opendkim-2.9.0 (centos) pypolicyd-spf-1.3.1 (epel) /var/log/maillog Dec 11 16:52:09 inet18 setroubleshoot: SELinux is preventing /usr/bin/perl from read access on the file online. For complete SELinux messages. run sealert -l 62006e35-dcc8-4a4f-8e10-9f34757f3a4a Dec 11 16:52:10 inet18 setroubleshoot: SELinux is

On 10/03/2017 11:32 AM, ToddAndMargo via samba wrote: > On 10/03/2017 05:33 AM, Rowland Penny via samba wrote: >> Sorry if some of these sound like teaching your grandmother to suck >> eggs, but it is better to say them than not;-) >> >> Rowland > > Hi Rowland, > >    I appreciate the the help!  You did exactly what I > ask for, which was to let it rip.