lockdown class

[Russell Coker <russell@coker.com.au>]

allow systemd_modules_load_t systemd_modules_load_t:lockdown integrity;
allow udev_t udev_t:lockdown confidentiality;

I've seen access that caused the above to be generated from audit2allow.

/var/log/audit/audit.log.1:type=AVC msg=audit(1607515838.132:56): avc:  denied  
{ confidentiality } for  pid=253 comm="systemd-udevd" lockdown_reason="use of 
tracefs" scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tclass=lockdown permissive=1

Above is the only log entry I've got for that from my previous testing (I 
haven't been able to reproduce whatever it was that caused the 
systemd_modules_load_t to get that audited).

https://www.paul-moore.com/blog/d/2020/03/linux_v56.html

I've read the above blog post and I'm still not sure exactly how we are to use 
it.  Do I allow this for systemd_modules_load_t because loading modules is an 
integrity issue?  Do I allow it for udev_t because changing device names etc 
allows universal MITM attacks?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/