11:52 a.m.
Hi,
We (SUSE) would like to introduce an "audit" group for log read access.
This would be handled only by patching the .spec file to create the
group and modify the permissions of the default log dir/file to:
drwxr-x--- 1 root audit 322 25. Okt 21:06 /var/log/audit/
-rw-r----- 1 root audit 1815972 26. Okt 22:23 /var/log/audit/audit.log
No source code modifications are required, as log_group_parser() should
handle invalid entries.
If an enforcement or warning is required for when log_group is not
using the default "audit" group, it should be easy to do as well.
For those wondering, Common Criteria seems to be fine with this
modification.
Excerpt from SUSE's CC certification (RH's seems to match):
---- begin ----
6.2.1.4 Restricted audit review (FAU_SAR.2)
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except
those
users that have been granted explicit read-access.
Application Note: The protection of the audit records is based on the Unix permission bit
settings defined by FDP_ACC.1(PSO) supported by FDP_ACF.1(PSO).
---- end ----
Please let me know of your concerns, if any.
I have a working patch that I can submit right away in case this gets an
ok.
Cheers,
Enzo
12:16 p.m.
Hello,
On Wednesday, January 20, 2021 12:52:24 PM EST Enzo Matsumiya wrote:
We (SUSE) would like to introduce an "audit" group for log
read access.
This would be handled only by patching the .spec file to create the
group and modify the permissions of the default log dir/file to:
drwxr-x--- 1 root audit 322 25. Okt 21:06 /var/log/audit/
-rw-r----- 1 root audit 1815972 26. Okt 22:23 /var/log/audit/audit.log
No source code modifications are required, as log_group_parser() should
handle invalid entries.
If an enforcement or warning is required for when log_group is not
using the default "audit" group, it should be easy to do as well.
For those wondering, Common Criteria seems to be fine with this
modification.
Excerpt from SUSE's CC certification (RH's seems to match):
---- begin ----
6.2.1.4 Restricted audit review (FAU_SAR.2)
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit
records, except those users that have been granted explicit read-access.
Application Note: The protection of the audit records is based on the Unix
permission bit settings defined by FDP_ACC.1(PSO) supported by
FDP_ACF.1(PSO).
---- end ----
Please let me know of your concerns, if any.
This might go against the DISA STIG, but otherwise this is using the audit
system as intended.
I have a working patch that I can submit right away in case this gets
an
ok.
I consider the audit.spec file to be an example to help others with packaging.
But I'm not entirely sure if it's 100% in sync with Fedora since they make
arbitrary policy changes like removing gcc and make from the build root which
then causes specfile updates. If you want to submit a patch, feel free. I
would apply it as an example to others.
Best Regards,
-Steve
3:39 p.m.
On 01/20, Steve Grubb wrote:
This might go against the DISA STIG, but otherwise this is using the
audit
system as intended.
Ah yes, you're right. I checked and it seems so for RH, but not for SUSE.
Good catch, though.
I consider the audit.spec file to be an example to help others with
packaging.
But I'm not entirely sure if it's 100% in sync with Fedora since they make
arbitrary policy changes like removing gcc and make from the build root which
then causes specfile updates. If you want to submit a patch, feel free. I
would apply it as an example to others.
Thanks. We also have some modifications to the specfile.
So what I'm getting from your reply is it's up to the OS vendor to provide,
or not, such modification -- i.e. it's more of a general OS problem than audit's
problem. Is that correct?
Best Regards,
-Steve
Cheers,
Enzo
5:15 p.m.
On Wednesday, January 20, 2021 4:39:11 PM EST Enzo Matsumiya wrote:
>I consider the audit.spec file to be an example to help others
with
>packaging. But I'm not entirely sure if it's 100% in sync with Fedora
>since they make arbitrary policy changes like removing gcc and make from
>the build root which then causes specfile updates. If you want to submit
>a patch, feel free. I would apply it as an example to others.
Thanks. We also have some modifications to the specfile.
So what I'm getting from your reply is it's up to the OS vendor to provide,
or not, such modification -- i.e. it's more of a general OS problem than
audit's problem. Is that correct?
I consider it to be an end user choice. Because if you set the log_group, you
may need to do a chgrp command to get your logs in order. And I don't know
who should get access. Would it be wheel or a special audit-view group? To
me, it just seems like any choice I make may not work for everyone.
But you're welcome to send a patch if you want.
-Steve
1380
days inactive
1380
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
Enzo Matsumiya -
Steve Grubb