Agreed with Stephen. We authenticate kernel and rootfs together so there is no value added to move the policy to the kernel.
On 2/9/15, 10:38 AM, "Stephen Smalley" <[email protected]> wrote: >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 <[email protected]> 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 >> <[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]. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
