No, named.log and query.log are in the default locations in /var/named/data it was just that rsyslogd couldn't read files in the data dir because of the context differences. --Matthew Wilkinson -----Original Message----- From: Simon Sekidde [mailto:ssekidde@xxxxxxxxxx] Sent: Wednesday, September 20, 2017 16:00 To: Wilkinson, Matthew Cc: Lukas Vrabec; selinux@xxxxxxxxxxxxxxxxxxxxxxx; Zdenek Pytela Subject: Re: Unable to use audit2allow on avc denials [This is an external email. Be cautious with links, attachments and responses.] ********************************************************************** ----- Original Message ----- > From: "Matthew Wilkinson" <MatthewWilkinson@xxxxxxxxxxxxxxxxx> > To: "Lukas Vrabec" <lvrabec@xxxxxxxxxx>, > selinux@xxxxxxxxxxxxxxxxxxxxxxx, "Zdenek Pytela" <zpytela@xxxxxxxxxx> > Sent: Wednesday, September 20, 2017 7:06:16 AM > Subject: 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 > Why is named.log in the /var/cache directory? Should it not be in /var/log? This might explain why you are getting the SELinux warning > 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://people.redhat.com/sgrubb/audit/ > 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 > -- Simon Sekidde gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
