On Fri, Sep 24, 2021 at 11:12 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > Looks like Fedora policy allowed both permissions unconditionally (no > boolean) to all unconfined domains. > So SECINITSID_KERNEL checks will pass but are rather pointless unless > Fedora decides to define separate > integrity/confidentiality rules and wrap them each with a boolean > (e.g. allow_kernel_integrity_violation, > allow_kernel_confidentiality_violation) so that an admin can disable > them to enforce lockdown independently > of the lockdown module. > > Android policy allows all domains :lockdown confidentiality but > prohibits (neverallow) integrity permission from > being allowed on user (production) builds. They do allow apps > :lockdown integrity on debug builds for debugfs > kcov usage, so that rule would need to be fixed if switching to always > using SECINITSID_KERNEL or the checks will > start failing. Thanks Stephen. > Did all the issues around invoking audit from arbitrary contexts in > which security_locked_down() is called get sorted? > If not, we'll still have that as a potential problem if permission is > denied or an auditallow rule is defined on lockdown. I believe the only issue was the eBPF code and that was resolved in a separate patch that is already upstream. > Can we get Linux distro and Android folks to speak as to whether they > consider the check in this reduced form to still be useful or whether > we should just remove it altogether? Yes, that's probably going to be the deal breaker. However as the day goes on I'm growing more fond of just ripping out that SELinux hook and being done with it. -- paul moore www.paul-moore.com
