Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Russell Coker <russell@coker.com.au>
To:     selinux-refpolicy@vger.kernel.org
Subject: lockdown class
Date:   Fri, 11 Dec 2020 18:01:58 +1100
Message-ID: <2911391.mirxchbQ87@liv>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

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/