Oh, I must have misinterpreted something else that I read then. Having said that, not relying on any userspace code for loading the policy would still be a pretty cool feature IMHO.
-- Nick On Sun, Feb 8, 2015 at 7:32 PM, Stephen Smalley <[email protected]> wrote: > 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 <[email protected]> wrote: >> On Sun, Feb 8, 2015 at 5:26 PM, Stephen Smalley >> <[email protected]> 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. -- Nick Kralevich | Android Security | [email protected] | 650.214.4037 _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
