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/