Interesting, I discovered auditd dead on a RHEL7 server a few days ago; no logs as to why it stopped. "/sbin/service auditd restart" will kick it back online, FYI. Mark Salowitz, CTR CTS II PaaS Engineer USCG Operations Systems Center -----Original Message----- From: Wilkinson, Matthew [mailto:MatthewWilkinson@xxxxxxxxxxxxxxxxx] Sent: Wednesday, September 20, 2017 10:06 AM To: Lukas Vrabec; selinux@xxxxxxxxxxxxxxxxxxxxxxx; Zdenek Pytela Subject: [Non-DoD Source] RE: Unable to use audit2allow on avc denials Sure thing, here is the AVC in the /var/log/messages file. I don't see this in /var/log/audit/audit.log but I see other logs in there. Sep 20 09:03:14 redacted kernel: type=1400 audit(1505916193.999:16716): avc: denied { read } for pid=33245 comm="in:imfile" name="named.log" dev="dm-9" ino=143 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:named_cache_t:s0 tclass=file Srangely, auditd doesn't seem to be running and systemctl can't interact with it. Possibly because of a dependency Failed to stop auditd.service: Operation refused, unit auditd.service may be requested by dependency only. See system logs and 'systemctl status auditd.service' for details. ● auditd.service - Security Auditing Service Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2017-09-13 14:06:04 CDT; 6 days ago Docs: man:auditd(8) https://urldefense.proofpoint.com/v2/url?u=https-3A__people.redhat.com_sgrubb_audit_&d=DwIGaQ&c=0NKfg44GVknAU-XkWXjNxQ&r=iohgjlRx8rzsacNUP-p6Uoa5Wl3Ea1utSdxGRRALEQk&m=aWI8MBw_cUygcu_Tv-ungZe6vMzHsORLp6MhNJmjZzc&s=a1RvhMqz_qHqECOCxT5oqGGLiFD556ddBYZNJM1fQno&e= Process: 911 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS) Process: 910 ExecStart=/sbin/auditd -n (code=exited, status=6) Main PID: 910 (code=exited, status=6) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. --Matthew Wilkinson -----Original Message----- From: Lukas Vrabec [mailto:lvrabec@xxxxxxxxxx] Sent: Wednesday, September 20, 2017 01:55 To: selinux@xxxxxxxxxxxxxxxxxxxxxxx Subject: Re: Unable to use audit2allow on avc denials [This is an external email. Be cautious with links, attachments and responses.] ********************************************************************** On 09/20/2017 08:09 AM, Zdenek Pytela wrote: > > > On Mon, Sep 18, 2017 at 6:55 PM, Wilkinson, Matthew > <MatthewWilkinson@xxxxxxxxxxxxxxxxx > <mailto:MatthewWilkinson@xxxxxxxxxxxxxxxxx>> wrote: > > Has anyone seen SELinux log to /var/log/messages but *not* to > /var/log/audit/audit.log? I have a situation that is being denied by > SELinux and logging avc denials to /var/log/messages, however I > can't determine a way to fix it because I get nothing for this > denial logged to /var/log/audit/audit.log. This prevents me from > generating a policy using audit2allow or sealert. > > Situation: I have a RHEL 7-based server which is running bind-chroot > and I'd like for rsyslog to collect and send the named.log and > query.log to our centralized rsyslog server. With SELinux in > enforcing mode, rsyslog cannot read the named logs. > > Do I need to write my own custom SELinux policy? > > Hi Matthew, > > I am afraid a new policy would not help you. Is auditd running and > writing other events (like intentionally triggered ones) to the audit.log? > Good question, is auditd running and writing other events? Also, it will be very helpful if you attach your AVC. There can be situation when auditd is not running yet during boot, so AVCs are logged into journal/syslog. Please attach AVC and we can move forward. Lukas. > Subsequent question, how the AVC's look like? Creating a policy module > might not be the best solution to your problem. > > -- > > Zdenek Pytela, Technical support engineer and team lead Customer > Engagement and Experience, Red Hat Czech > E-mail: zpytela@xxxxxxxxxx <mailto:zpytela@xxxxxxxxxx>, IRC: zpytela > > > _______________________________________________ > selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe > send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
