Yes there is little value in doing the work also I think it'll be hard to get ever accepted in the mainline kernel. However it's awesome to hear that the additional support for extended attributes may have already been added into cpio. I looked into this 2 or 3 years ago I was going to implement it but I had too much on my plate at the time. On Feb 9, 2015 7:52 AM, "Tai Nguyen (tainguye)" <[email protected]> wrote:
> 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]. >
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
