I have to ask, why does selinux care? It's supposed to have second vote after DAC permission checks. In this case the DAC control is the boot parameter. There might be a missing dont_audit in the policy. Is there a related policy bz for this issue?

Well SELinux disable module loading by default, unless there is a specific domain loading it.
That's done for security reasons (e.g. avoid a rogue script to load something in the kernel).

There is no possibility to craft a "dontaudit" for a specific module name, SELinux is not aware of this, it only handles operations (e.g. "module_request") based on calling context.
So I see no other possibility than enhancing the audit side of things.

This really seems like a policy problem. The module should have a type associated with it. The subject is dhcp_t, which should be presumed to need to allow network module loading.

This is how I understand the problem:

The avc is a direct effect of disabling IPv6 on the kernel command line.
I don't think this particular permission should be allowed in selinux-policy,
loading a network kernel module is rather a job of NetworkManager etc, neither
it should be dontaudited, exposing the AVC is there to notify the administrator
about a possible problem, not to mention that dontaudit rules make troubleshooting harder.

Anyway, this does not seem to be the point of the RFE: the problem is
selinux-policy has no means to discern between different permissions request
as it only understands labels. While it generally is correct to audit not
allowed permission, it is reasonable to not audit just some of them, based
on different criteria than the source-target-class-permission quadruple, and
let the others still be audited.
This cannot be handled in the policy, neither a local policy module can be used to do so.

The problem is that in the network world, there are auto-loading kernel modules for each protocol. Meaning, they stay out of the way until needed and then on-demand load. NetworkManager is not involved what-so-ever.

SE Linux is supposed to have second vote, meaning that if DAC disables something, then SE Linux shouldn't see it or complain. Maybe the LSM hook is in the wrong place in the kernel? Or maybe the modules need types so that control can be better handled. For example, it's normal for named_t to request net-pf-10. It is not normal for it to request net-pf-31.

Hi Steve,

The RFE is about being able to filter more precisely on AVCs, not about how to enhance SELinux to be more fine grained.
If you disagree on the proposal, I have no problem with that, I just believe it would be very useful, I see regularly cases where customers request details / complain on various AVCs they hit, mostly due to how they disable IPv6 and when they want to stick to using ipv6.disable=1 on the kernel command line, I have no proper solution to offer to avoid having them get this "module_request" AVC.

Renaud.

Hello Renaud,

The proposal doesn't really spell out where filtering is being asked for. Would that be in auditd? Ausearch?

Auditd does not do any filtering at all. It's job is to unload the kernel queue and get them to disk and distribute the events to plugins.

In terms of ausearch, can't grep + sed be used?

ausearch --start today -if /var/log/audit/audit.log | grep -v 'time->' | tr '\n' ' ' | sed -e 's/----/\n/g' | grep AVC | grep -v net-pf-10 | sed -e 's/ type=/\ntype=/g'

Regardless, the AVC is generated by SE Linux. It is triggering in spite of a DAC check that should prevent the need for a MAC response. Some code in the kernel may need fixing to do the DAC denial before the LSM hook.

Hi Steve,

The filtering would have to be done on Rule side, to completely avoid getting such AVC being noticed at all.
Filtering in ausearch is not useful because it's too late: usually customers contact us as soon as an AVC pops up (objective being 0 AVC at all) because their security team complains about receiving alerts.

Renaud.

To set expectations...I am not the audit maintainer.

If this is asking for filtering at the moment the event is created, then that is a kernel bz and would need to be transferred to the kernel audit subgroup for evaluation.

Since SE Linux creates the whole event and only uses audit as a way to get the event to user space. The only place the audit system would see the event is at the exclude filter. There is no kmod audit field to filter on. That information never leaves the LSM subsytem (See LSM_AUDIT_DATA_KMOD).

There might be ways to write an exclude rule on -F msgtype=KERN_MODULE -F comm=dhcpd ...that is if it's a full event and not just a AVC.

With the DHCP snippet above, we get 4 AVCs, but nothing else:

# ausearch -m avc,user_avc -ts boot
----
time->Fri Oct 14 07:31:46 2022
type=PROCTITLE msg=audit(1665725506.240:155): proctitle=2F7573722F7362696E2F6468637064002D66002D6366002F6574632F646863702F64686370642E636F6E66002D75736572006468637064002D67726F7570006468637064002D2D6E6F2D706964
type=SYSCALL msg=audit(1665725506.240:155): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7f54c04fc938 a2=0 a3=0 items=0 ppid=1 pid=15612 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dhcpd" exe="/usr/sbin/dhcpd" subj=system_u:system_r:dhcpd_t:s0 key=(null)
type=AVC msg=audit(1665725506.240:155): avc:  denied  { search } for  pid=15612 comm="dhcpd" name="net" dev="proc" ino=11606 scontext=system_u:system_r:dhcpd_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=dir permissive=0
----
time->Fri Oct 14 07:31:46 2022
type=PROCTITLE msg=audit(1665725506.241:156): proctitle=2F7573722F7362696E2F6468637064002D66002D6366002F6574632F646863702F64686370642E636F6E66002D75736572006468637064002D67726F7570006468637064002D2D6E6F2D706964
type=SYSCALL msg=audit(1665725506.241:156): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7f54c04fc938 a2=0 a3=0 items=0 ppid=1 pid=15612 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dhcpd" exe="/usr/sbin/dhcpd" subj=system_u:system_r:dhcpd_t:s0 key=(null)
type=AVC msg=audit(1665725506.241:156): avc:  denied  { search } for  pid=15612 comm="dhcpd" name="net" dev="proc" ino=11606 scontext=system_u:system_r:dhcpd_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=dir permissive=0
----
time->Fri Oct 14 07:31:46 2022
type=PROCTITLE msg=audit(1665725506.241:157): proctitle=2F7573722F7362696E2F6468637064002D66002D6366002F6574632F646863702F64686370642E636F6E66002D75736572006468637064002D67726F7570006468637064002D2D6E6F2D706964
type=SYSCALL msg=audit(1665725506.241:157): arch=c000003e syscall=41 success=no exit=-97 a0=a a1=2 a2=11 a3=31 items=0 ppid=1 pid=15612 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dhcpd" exe="/usr/sbin/dhcpd" subj=system_u:system_r:dhcpd_t:s0 key=(null)
type=AVC msg=audit(1665725506.241:157): avc:  denied  { module_request } for  pid=15612 comm="dhcpd" kmod="net-pf-10" scontext=system_u:system_r:dhcpd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
----
time->Fri Oct 14 07:31:46 2022
type=PROCTITLE msg=audit(1665725506.241:158): proctitle=2F7573722F7362696E2F6468637064002D66002D6366002F6574632F646863702F64686370642E636F6E66002D75736572006468637064002D67726F7570006468637064002D2D6E6F2D706964
type=SYSCALL msg=audit(1665725506.241:158): arch=c000003e syscall=41 success=no exit=-97 a0=a a1=2 a2=11 a3=1000 items=0 ppid=1 pid=15612 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dhcpd" exe="/usr/sbin/dhcpd" subj=system_u:system_r:dhcpd_t:s0 key=(null)
type=AVC msg=audit(1665725506.241:158): avc:  denied  { module_request } for  pid=15612 comm="dhcpd" kmod="net-pf-10" scontext=system_u:system_r:dhcpd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0