Not as far as I know. Original SELinux kernel patch did have the kernel initiate the policy load from the root filesystem, but even that required a populated rootfs before policy load. SELinux in mainline has always deferred initial policy load to init as that was preferred by the kernel developers.
On Sun, Feb 8, 2015 at 9:01 PM, Nick Kralevich <n...@google.com> wrote: > On Sun, Feb 8, 2015 at 5:26 PM, Stephen Smalley > <stephen.smal...@gmail.com> wrote: >> >> Also, since the rootfs is necessarily unpacked before init is run and >> therefore before policy has been loaded, it is unclear exactly what >> will happen if they try to set SELinux security contexts at that time. > > This is something I've been hoping that we could fix. IIRC, there's a > kernel option to embed the policy into the kernel itself, so that it's > loaded before any userspace code is run. Unfortunately, I don't know > how this works and what it would take to append the policy to the > kernel at build time. > >> In old kernels it would have just failed; in modern kernels, the >> deferred security context mapping support might allow it to work >> (context string will be saved off at the time of setting; incore inode >> will be temporarily treated as unlabeled; when policy load happens, >> context strings will be validated and the incore inodes will start >> being treated as having that context), but that's not something that >> we have ever tested. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
