similar to: More avc's wrt to email

On 12/04/2014 03:22 PM, James B. Byrne wrote: > On Thu, December 4, 2014 12:29, James B. Byrne wrote: >> Re: SELinux. Do I just build a local policy or is there some boolean setting >> needed to handle this? I could not find one if there is but. . . >> > Anyone see any problem with generating a custom policy consisting of the > following? > > grep avc

On Fri, December 5, 2014 04:53, Daniel J Walsh wrote: > > On 12/04/2014 03:22 PM, James B. Byrne wrote: >> On Thu, December 4, 2014 12:29, James B. Byrne wrote: >>> Re: SELinux. Do I just build a local policy or is there some boolean >>> setting >>> needed to handle this? I could not find one if there is but. . . >>> >> Anyone see any problem

On Thu, December 4, 2014 12:29, James B. Byrne wrote: > > Re: SELinux. Do I just build a local policy or is there some boolean setting > needed to handle this? I could not find one if there is but. . . > Anyone see any problem with generating a custom policy consisting of the following? grep avc /var/log/audit/audit.log | audit2allow #============= amavis_t ============== allow

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

I am seeing these avc messages on a newly commissioned and up-to-date CentOs-6 virtual guest: ---- time->Thu Dec 4 12:14:58 2014 type=SYSCALL msg=audit(1417713298.610:60522): arch=c000003e syscall=2 success=no exit=-13 a0=7fd70e6de1e6 a1=0 a2=1b6 a3=0 items=0 ppid=2698 pid=4294 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2784 comm="trivial-rewrite"

we have remote server running as a guest instance on a kvm host. This server acts as a public MX service for our domains along with providing a backup for our Mailman mailing lists. It also has a slave named service. while tracking down a separate problem I discovered these avc anomalies and ran audit2allow to see what was required to eliminate them. All the software is either from CentOS or

Installed Packages Name : postfix Arch : x86_64 Epoch : 2 Version : 2.6.6 Release : 6.el6_5 Size : 9.7 M Repo : installed >From repo : updates I am seeing several of these in our maillog file after a restart of the Postfix service: Apr 23 12:48:27 inet08 setroubleshoot: SELinux is preventing /usr/libexec/postfix/smtp from 'read, write'

On Mon, December 8, 2014 20:01, Daniel J Walsh wrote: > > rpm -q selinux-policy > > selinux-policy-3.7.19-260.el6 is the current policy in development. >> Thank you. >>>> #============= postfix_showq_t ============== >>>> allow postfix_showq_t tmp_t:dir read; >>> Any reason postfix would be listing the contents of /tmp or /var/tmp? >>>

I'm busy setting up amavisd-new on a CentOS 5.0 box - and believe I've got it working well enough that I can switch selinux enforcing back on again. I've done the usual- - grab a chunk of the audit.log that is relevant to all the actions that would be denied. - do 'cat audit.log | audit2allow -M amavis' to generate the module - amavis.te looks like: module amavis 1.0;

Hello CentOS Docs People! I recently used the Amavisd howto to setup a couple of mailservers, which saved me from hours of searching online and reading novels of documentation. Since Ned is taking a little break from the Amavisd page, I would like to help contribute. There were a few things I'd like to add, like GTUBE/EICAR testing and SELinux config lines. My wiki username is WilliamFong.

Regarding the brilliant wiki site: http://wiki.centos.org/HowTos/Amavisd?highlight=%28Amavis%29 I faced the following issue on CentOS 6.2: "Spamassind" saves each message and its attached part in a folder in clamd accesses the folder, creates itself a temporary folder and deletes it afterwards. This was stopped by SELinux and caused the virus scan to fail. This action causes SE-Linux

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

Not a problem ... sharing a solution (this time)! Please correct my understanding of the process, if required. "i_stream_read() failed: Permission denied" is an error message generated when a large-ish file (>128kb in my case) is attached to a message that has been passed to Dovecot's deliver program when SELinux is being enforced. In my case, these messages are first run

Gordon, Thank you for your help on this. Still not working... On 04/26/2017 06:27 PM, Gordon Messmer wrote: > On 04/26/2017 12:29 AM, Robert Moskowitz wrote: >> But the policy generates errors. I will have to submit a bug report, >> it seems > > > A bug report would probably be helpful. > > I'm looking back at the message you wrote describing errors in >

Hi, I guess this is a bit OT but perhaps someone has encountered this issue before. On a CentOS 6.3 x86_64 box I have installed postfix and dspam from EPEL. Dspam is configured to listen on port 10026. After having configured dspam and postfix I start dspam and then postfix and I see the following AVC message in audit.log: type=AVC msg=audit(1350920492.936:400): avc: denied { name_bind }

On 12/12/2017 04:37 AM, Nicolas Kovacs wrote: > Spamassassin has been working nicely on my main server running CentOS 7 > and Postfix. SELinux is activated (Enforcing). > ... > SELinux is preventing /usr/bin/perl from 'read, write' accesses on the > file /var/log/spamassassin/.spamassassin/bayes_toks. > ... > Source Context system_u:system_r:spamd_t:s0

after cleaning up a bunch or selinux alerts, I update and wham, clamav/clamd/clamav-db make me assert contexts again to /var/clamav like... chcon -t clamd_t clamav -R which temporarily solves the problem but it would be better if it were policy and not file contexts. So I search and see for some reason, /var/clamav is ignored... # grep clam /etc/selinux/targeted/contexts/files/file_contexts

Hi: I have been using Dovecot for well over a year now and it has always worked with few problems. The mail setup is not simple... Postfix+MailScanner+ClamAV+Docvecot+MySql+postfix.admin... just to mention the major things. The system is CentOS 5.3 on VMware. The maildir is on an NFS share, index and control is local. About a month ago I thought I upgraded from 1.1.x to 1.2.x. by doing an

On 09/09/2018 07:19 AM, Daniel Walsh wrote: > sesearch -A -s httpd_t -t system_conf_t -p read > > If you feel that these files should not be part of the base_ro_files > then we should open that for discussion. I think the question was how users would know that the policy allowed access, as he was printing rules affecting httpd_t's file read access, and looking for

Hi! Am 09.04.20 um 10:07 schrieb Rob Kampen: [...] > I too had fail2ban fail after an otherwise successful yum update. Mine occurred in Feb when my versions of firewalld etc were updated to the versions you show. Thus far I have not had the opportunity to sort the problem. Lockdown has been quite busy so far, hopefully some slower times coming next week. Yeah, those pesky real-life biological