[bug#54309] [PATCH] services: auditd: use exclusive log directory for auditd

[fesoj000]

Hi,

On 3/9/22 8:36 PM, Maxime Devos wrote:
> fesoj000 schreef op wo 09-03-2022 om 20:21 [+0100]:
> > Currently auditd writes logs to /var/log/audit.log. This is a problem because
> > auditd changes the permissions of the directory audit.log lives in to
> > 700.
>
> Why is auditd doing this?  Can this behaviour be patched out? Is there
> an upstream reportThis is the default behavior. auditd will always change the 
> permissions, but
some attributes for this permission change can be configured in the config file.

This behavior could be patched, but i don't think this is a good idea. Even the
manpages assume /var/log/audit as the default log directory in some paragraphs.

The auditd logfile contains events which can be usefull for debugging but
usually this information is used in the aftermath of an cyberattack to learn 
more
about what happend. It is even recommended to use a separate partition for
/var/log/audit. auditd measures disk space and having /var/log/audit on a 
separate
partition would deny unrelated processes from filling up the disk, effectively
disabling audit logging.

I think having /var/log/audit as the default log directory for auditd would not
hurt. This would be more in line with other distros and further would allow to 
use
a different partition.

> >   /var/log usually has 755, this is assumed by some services. postgresql
> > for example, fails when used together with auditd.
>
> Why does postgresql care about the group and other bits?
> Could postgresql be modified not to care?
Maybe postgresql could be changed to gracefully handle this, but i am not sure 
what
the benefit would be in this context. In my mind this is obviously a problem of 
how
auditd is handled currently by auditd-service-type.

Postgresql might be not the only service behaving this way. I did use 
postgresql as
an example because this was the case i run into.

> What are the reasons for changing the group and other bits?
> Perhaps that should be done by default by Guix when creating
> /var/log (POLA)?
guix creates /var/log as 755, auditd changes its log directory to prevent access
from unprivileged processes. Maybe auditd is paranoid in this case, but it is 
fine
as long as it gets its own directory.

> In any case, I would recommend adding to auditd.scm to make clear
> why the default log location is unacceptable.
The log location is configured by the configuration file. This configuration 
file is
generated by auditd-service-type. The upstream [0] default configuration uses
/var/log/audit as log directory. I think that documenting upstream default 
behavior
does not add much value here. In fact, i think we can remove the log_file 
statement
all together, because the built in default config uses /var/log/audit/audit.log 
[1].
I will prepare and test a new diff which removes the log_file statement.


[0] 
https://github.com/linux-audit/audit-userspace/blob/master/init.d/auditd.conf
[1] 
https://github.com/linux-audit/audit-userspace/blob/master/src/auditd-config.c#L314

BR