search for: audit2why

It says what it is my original post; that?s the output from audit2allow ?w (which is audit2why): Was caused by: The boolean allow_ypbind was set incorrectly. Description: Allow system to run with NIS Allow access by executing: # setsebool -P allow_ypbind 1 --- Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265...

On 6/6/17, 12:38 PM, "Daniel Walsh" <dwalsh at redhat.com> wrote: >I am asking if you run it again, does it change. If the boolean is set >the audit2why should say that the AVC is allowed. Well, if I just run audit2why again, it always tells me the same thing. However, I have now discovered that if I unset allow_ypbind, and then reset it to 1, audit2why then says type=AVC msg=audit(1496768649.872:1338): avc: denied { name_connect } for pid=24...

...the ability to connect to the database. I haven't seen any real problems on the site that uses the database. But I was just wondering if this message looks familiar to anyone. Or if it looks like something I should try to correct. I tried grepping through audit.log for haproxy and piping it to audit2why, but I don't get any useful response back: [root at db1:~] #grep haproxy /var/log/audit/audit.log | audit2why -M haproxy Nothing to do I'm open to your thoughts and opinions! Thanks, Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

...ase. I haven't seen any real problems on the site that uses the >> database. But I was just wondering if this message looks familiar to >> anyone. Or if it looks like something I should try to correct. >> >> I tried grepping through audit.log for haproxy and piping it to audit2why, >> but I don't get any useful response back: >> >> [root at db1:~] #grep haproxy /var/log/audit/audit.log | audit2why -M >> haproxy >> Nothing to do >> >> I'm open to your thoughts and opinions! >> >> Thanks, >> Tim >> >...

postfixadmin setup.php is claiming: *Error: Smarty template compile directory templates_c is not writable.* *Please make it writable.* *If you are using SELinux or AppArmor, you might need to adjust their setup to allow write access.* This goes away with 'setenforce 0', so it is an SELinux issue. I have tried both: restorecon -Rv /usr/share/postfixadmin and chcon -R -t

...[FAILED] Starting OpenDKIM Milter: opendkim: /etc/opendkim.conf: refile:/etc/opendkim/TrustedHosts: dkimf_db_open(): Permission denied [FAILED] I check the permissions and ownership on the file and everything seems normal. I then checked audit2why and got this: audit2allow: error: no such option: -- [root at inet08 opendkim]# audit2why -l -a type=AVC msg=audit(1399898848.286:2317): avc: denied { dac_read_search } for pid=15213 comm="opendkim" capability=2 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:sy...

I keep seeing this in my audit.logs: type=AVC msg=audit(1496336600.230:6): avc: denied { name_connect } for pid=2411 comm="dbus-daemon" dest=111 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket Was caused by: The boolean allow_ypbind was set incorrectly. Description: Allow system to run with NIS Allow

On 06/06/2017 09:41 AM, Vanhorn, Mike wrote: > It says what it is my original post; that?s the output from audit2allow ?w (which is audit2why): > > Was caused by: > The boolean allow_ypbind was set incorrectly. > Description: > Allow system to run with NIS > > Allow access by executing: > # setsebool -P allow_ypbind 1 > > --- > Mike VanHorn > Senior Computer Systems Administrator > College of...

On 06/06/2017 01:19 PM, Vanhorn, Mike wrote: > On 6/6/17, 12:38 PM, "Daniel Walsh" <dwalsh at redhat.com> wrote: > >> I am asking if you run it again, does it change. If the boolean is set >> the audit2why should say that the AVC is allowed. > Well, if I just run audit2why again, it always tells me the same thing. However, I have now discovered that if I unset allow_ypbind, and then reset it to 1, audit2why then says > > type=AVC msg=audit(1496768649.872:1338): avc: denied { name_connect }...

Thanks for your help. I did pick up an additional entry in the audit file : type=AVC msg=audit(1504561395.709:10196): avc: denied { execute } for pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi" dev="dm-0" ino=537182029 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file Unfortunately, I am not sure how the

On 12/28/2016 05:11 AM, Todor Petkov wrote: > On Wed, Dec 28, 2016 at 5:18 AM, Robert Moskowitz <rgm at htt-consult.com> wrote: >> Which is why I wonder if there is some different config for the C7.3 version >> of apache. >> >> Or something with the C7-arm build... > Can you check for SELinux warnings/errors in /var/log/audit/audit.log? Good advice. As I

...t;> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos > Hi, > > after 'setenforce 0' check the /var/log/audit/audit.log: > > # grep /var/log/audit/audit.log | audit2why Don't I need a search string in that grep command? > to see where the problem could be. Anyway the last three entries are: type=AVC msg=audit(1487695678.704:128): avc: denied { write } for pid=2055 comm="httpd" name="templates_c" dev="sda3" ino=786958 s...

...o the > database. I haven't seen any real problems on the site that uses the > database. But I was just wondering if this message looks familiar to > anyone. Or if it looks like something I should try to correct. > > I tried grepping through audit.log for haproxy and piping it to audit2why, > but I don't get any useful response back: > > [root at db1:~] #grep haproxy /var/log/audit/audit.log | audit2why -M haproxy > Nothing to do > > I'm open to your thoughts and opinions! > > Thanks, > Tim setsebool -P haproxy_connect_any 1 Alexander

...44350.289:339): avc: denied { read } for pid=2141 comm="httpd" name="family" dev="sda3" ino=262199 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=dir permissive=0 I ran into the same problem, I think. I ran "audit2why" and passed in the AVC. It suggested a pair of booleans I've never seen before. # audit2why type=AVC msg=audit(1483077583.703:1539671): avc: denied { read } for pid=11162 comm="httpd" name="courier-pythonfilter" dev="dm-0" ino=533228 scontext=system_u:sys...

Hello, This is somehow off-topic, since the problem appears on a modified CentOS-6.2 (turned into a xen-4.1 host) : I get SELinux errors, and I'm not able to understand them. From audit2why : type=AVC msg=audit(1343724164.898:298772): avc: denied { mac_admin } for pid=12399 comm="restore" capability=33 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2 ... and from audit2allow...

On 30.07.2019 20:07, Tom Diehl via dovecot wrote: > > Does anyone have an Idea how to fix this? > > Regards, > Perhaps see if there are any denials in SELinux audit log: sudo grep denied /var/log/audit/audit.log | grep dovecot | audit2allow -a Good luck, Reio

...rrent policy allow httpd_t httpd_sys_script_t:process signull; Noting that on my 7.6 system with selinux enforcing with selinux policy packages at version 3.13.1-229, it notes that your denial would not happen. If you don't have it installed policycoreutils-python provides the audit2allow and audit2why binaries which can help you generate a policy to avoid this denial if you want. Also, I often find that to truly diagnose the issue, I need to run the following: # semodule --disable_dontaudit --build # setenforce permissive # tail -f /var/log/audit/audit.log | grep denied | tee ~/denials.out .....

...005 egid=1005 sgid=1005 fsgid=1005 tty=(none) ses=4294967295 comm="imap" exe="/usr/libexec/dovecot/imap" subj=system_u:system_r:dovecot_t:s0 key=(null) type=PROCTITLE msg=audit(1586604621.638:6737): proctitle="dovecot/imap" I have SELinux enabled, on CentOS. If I run: audit2why < /var/log/audit/audit.log I get: type=AVC msg=audit(1586601301.044:6707): avc: denied { write } for pid=9930 comm="imap" name="Maildir" dev="dm-3" ino=438370738 scontext=system_u:system_r:dovecot_t:s0 tcontext=unconfined_u:object_r:etc_runtime_t:s0 tclass=dir p...

...> type=PROCTITLE msg=audit(1586604621.638:6737): proctitle="dovecot/imap" </div> <div> <br> </div> <div> I have SELinux enabled, on CentOS. </div> <div> If I run: </div> <div> audit2why < /var/log/audit/audit.log </div> <div> <br> </div> <div> I get: </div> <div> type=AVC msg=audit(1586601301.044:6707): avc: denied { write } for </div> <div> pid=9930 comm="imap" n...

...ting /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck. ***** Plugin catchall (100. confidence) suggests **************************... So I enabled SELinux and started troubleshooting with audit2why. [root at web1:~] #setenforce 1 [root at web1:~] #getenforce Enforcing And I'm seeing messages like these: [root at web1:~] #grep appd /var/log/audit/audit.log | audit2why -w type=AVC msg=audit(1431305820.292:393420): avc: denied { write } for pid=27289 comm="java" path="/...