Bug#759604: auditd: Please make auditd log readable by the adm group
On 06/11/2017 12:41, Laurent Bigonville wrote: > The proper way to monitor the audit log would be to use audispd and > create a daemon responding to the events (this is what setroubleshoot is > doing). > > Parsing the logs manually is meh (especially if you take into account > that the kernel is not using the proper audit event id) While I agree it's the Right Thing To Do, right now aa-notify just parses the log and it works OK. It just needs the proper permissions on the log to do that without being root. Can't we implement the permission solution as a first step ? Even if it's not a perfect solution, it just works, and I don't see any harmful side-effect - that's what the adm group is for, IMO. Of course, please correct me if I'm wrong ! Cheers, -- nodens
Bug#759604: auditd: Please make auditd log readable by the adm group
Le 05/11/17 à 18:24, Clément Hermann a écrit : Hi, now that apparmor is actually enabled by default, it would be nice to be able to use aa-notify without using sudo by applying nicoo's patch: https://anonscm.debian.org/cgit/collab-maint/audit.git/log/?h=nicoo/debian Can you please look into it ? Well, I'm not sure The proper way to monitor the audit log would be to use audispd and create a daemon responding to the events (this is what setroubleshoot is doing). Parsing the logs manually is meh (especially if you take into account that the kernel is not using the proper audit event id) Cheers, -- nodens
Bug#759604: auditd: Please make auditd log readable by the adm group
Hi, now that apparmor is actually enabled by default, it would be nice to be able to use aa-notify without using sudo by applying nicoo's patch: https://anonscm.debian.org/cgit/collab-maint/audit.git/log/?h=nicoo/debian Can you please look into it ? Cheers, -- nodens
Bug#759604: auditd: Please make auditd log readable by the adm group
Le Mon, 17 Aug 2015 11:21:45 +0200, intrigeri intrig...@debian.org a écrit : Hi, Laurent Bigonville wrote (17 Aug 2015 08:58:52 GMT) : Le Mon, 17 Aug 2015 10:37:00 +0200, intrigeri intrig...@debian.org a écrit : Sorry for not replying earlier. No problem, thanks for replying. The problem might be IIRC that the auditd daemon itself check the mode/owner/group of the files on disk before starting. I do not remembrer all the details though. Sorry, I should have been clearer. I've tested that this combination works just fine on current sid: * log_group = adm * dpkg-statoverride --update --add root adm 750 audit Oh OK, interesting. We need the check that by changing this we are not loosing some kind of US gouvernement certifications if we really care about this (auditd daemon follows some gouvernement recommendations/certification). Is there any practical value in complying to such recommendations in a single package, as long as the underlying base OS does not? (I suspect not, but that's a genuine question, not a rhetorical one: I have actually no idea how these things work, nor whether we have any Debian users who care about that.) I'm not too sure either to be honest. Maybe you could ask on the linux-au...@redhat.com mailing list? Yes, I can do that if needed, once we've clarified whether that's a goal worth pursuing (otherwise there's no point). I've no strong feeling about this. But I would be interested to see if upstream has something to say about this. Cheers, Laurent Bigonville Cheers,
Bug#759604: auditd: Please make auditd log readable by the adm group
Le Mon, 17 Aug 2015 10:37:00 +0200, intrigeri intrig...@debian.org a écrit : Hi, Hey, Sorry for not replying earlier. intrig...@debian.org wrote (28 Aug 2014 21:37:36 GMT) : currently, by default /var/log/audit is root:root / 0750, and /var/log/audit/audit.log is root:root / 0600. The convention for many log files in Debian is to make them readable by members of the adm group. Any reason not to do that for audit.log as well? This would unbreak apparmor-notify when auditd is running in its default configuration. I looked into it a bit closer, and the problem has two aspects. 1. There's a log_group directive in /etc/audit/auditd.conf, and I've verified that it's enough to make audit.log group-readable, with permissions 0640. On this side, the question then becomes: what would be the problem with setting `log_group = adm' by default? 2. For the parent directory (/var/log/audit), it's currently shipped as part of the package, so here we could simply ship it with 0710 permissions, owned by root:adm. I guess that #2 is no big issue: giving members of the adm group x permission on that directory should not be a problem in itself, would it? Addressing this only would not solve 100% of the problem I've reported initially, but at least it would allow one to fix it by simply modifying a conffile, as opposed to having to use dpkg-statoverride, which arguably requires a bit more expertise. Thoughts, anyone? The problem might be IIRC that the auditd daemon itself check the mode/owner/group of the files on disk before starting. I do not remembrer all the details though. We need the check that by changing this we are not loosing some kind of US gouvernement certifications if we really care about this (auditd daemon follows some gouvernement recommendations/certification). Maybe you could ask on the linux-au...@redhat.com mailing list? Cheers, Laurent Bigonville
Bug#759604: auditd: Please make auditd log readable by the adm group
Hi, Laurent Bigonville wrote (17 Aug 2015 08:58:52 GMT) : Le Mon, 17 Aug 2015 10:37:00 +0200, intrigeri intrig...@debian.org a écrit : Sorry for not replying earlier. No problem, thanks for replying. The problem might be IIRC that the auditd daemon itself check the mode/owner/group of the files on disk before starting. I do not remembrer all the details though. Sorry, I should have been clearer. I've tested that this combination works just fine on current sid: * log_group = adm * dpkg-statoverride --update --add root adm 750 audit We need the check that by changing this we are not loosing some kind of US gouvernement certifications if we really care about this (auditd daemon follows some gouvernement recommendations/certification). Is there any practical value in complying to such recommendations in a single package, as long as the underlying base OS does not? (I suspect not, but that's a genuine question, not a rhetorical one: I have actually no idea how these things work, nor whether we have any Debian users who care about that.) Maybe you could ask on the linux-au...@redhat.com mailing list? Yes, I can do that if needed, once we've clarified whether that's a goal worth pursuing (otherwise there's no point). Cheers, -- intrigeri
Bug#759604: auditd: Please make auditd log readable by the adm group
Hi, intrig...@debian.org wrote (28 Aug 2014 21:37:36 GMT) : currently, by default /var/log/audit is root:root / 0750, and /var/log/audit/audit.log is root:root / 0600. The convention for many log files in Debian is to make them readable by members of the adm group. Any reason not to do that for audit.log as well? This would unbreak apparmor-notify when auditd is running in its default configuration. I looked into it a bit closer, and the problem has two aspects. 1. There's a log_group directive in /etc/audit/auditd.conf, and I've verified that it's enough to make audit.log group-readable, with permissions 0640. On this side, the question then becomes: what would be the problem with setting `log_group = adm' by default? 2. For the parent directory (/var/log/audit), it's currently shipped as part of the package, so here we could simply ship it with 0710 permissions, owned by root:adm. I guess that #2 is no big issue: giving members of the adm group x permission on that directory should not be a problem in itself, would it? Addressing this only would not solve 100% of the problem I've reported initially, but at least it would allow one to fix it by simply modifying a conffile, as opposed to having to use dpkg-statoverride, which arguably requires a bit more expertise. Thoughts, anyone? Cheers, -- intrigeri
Bug#759604: auditd: Please make auditd log readable by the adm group
Hi, currently, by default /var/log/audit is root:root / 0750, and /var/log/audit/audit.log is root:root / 0600. The convention for many log files in Debian is to make them readable by members of the adm group. Any reason not to do that for audit.log as well? This would unbreak apparmor-notify when auditd is running in its default configuration. Ping? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759604: auditd: Please make auditd log readable by the adm group
Package: auditd Severity: normal Hi, currently, by default /var/log/audit is root:root / 0750, and /var/log/audit/audit.log is root:root / 0600. The convention for many log files in Debian is to make them readable by members of the adm group. Any reason not to do that for audit.log as well? This would unbreak apparmor-notify when auditd is running in its default configuration. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
