lockdown class

Russell Coker <[email protected]>
Newsgroups org.kernel.vger.selinux-refpolicy
Message-ID <2911391.mirxchbQ87@liv>
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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.