The closest approximation is what is already the case in Android: loading policy from the init program and the policy file unpacked from the initramfs image. In that case, the integrity of the init program and the policy file is the same as that of the kernel (as the kernel and initramfs are both part of the boot image and verified in the same way), so you wouldn't really gain anything by moving it to the kernel. It is much less direct in Linux distributions, where they defer loading to the init program and policy file from the real root filesystem.
On Mon, Feb 9, 2015 at 12:11 AM, Nick Kralevich <n...@google.com> wrote: > 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 > <stephen.smal...@gmail.com> 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 <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. > > > > -- > Nick Kralevich | Android Security | n...@google.com | 650.214.4037 _______________________________________________ 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.
