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. 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.
On Sun, Feb 8, 2015 at 8:17 PM, Stephen Smalley <stephen.smal...@gmail.com> wrote: > It hasn't been of interest for SELinux in typical Linux distributions > since they generally only use the rootfs briefly during initialization > and then pivot the real root into place, hiding the rootfs that was > unpacked from the initramfs. > rootfs is unpacked by the kernel from a cpio-formatted initramfs image > into a ramfs or tmpfs filesystem. The cpio format known to the cpio > utility and to the kernel does not know about extended attributes. > ramfs also does not support extended attributes except for the > relatively recent change to SELinux to support setting security > labels. tmpfs does have general xattr support and correct new inode > labeling, but is not the default for rootfs. Addressing this issue > requires extending cpio format, cpio utility, and kernel side to > support extended attributes. That work has been done very recently by > the Linux integrity measurement architecture (IMA) developers to > support their extended attributes, and should enable support for all > extended attributes, but I don't believe it is yet in any released > kernel. Patches and discussion have been ongoing on the > linux-security-module mailing list. > > On Sat, Feb 7, 2015 at 9:52 AM, Nick Kralevich <n...@google.com> wrote: >> Currently, Android's init.rc supports a seclabel entry for services. This >> allows you to specify an SELinux domain for a service, without relying on >> the transition rules defined by policy. >> >> One of the primary reasons why the seclabel entries exist is because the >> root filesystem doesn't support labeling. Labeling is only done on /system, >> not on rootfs. As a result, we can't rely on SELinux's built in domain >> transition code. >> >> Does anyone recall why the root filesystem doesn't support labeling? Is it >> just something which hasn't been implemented yet, or some more fundamental >> problem? >> >> We support setting the traditional file permissions on rootfs files, but not >> selinux labels, which seems odd to me. >> >> This came up in the context of >> https://android-review.googlesource.com/129923 >> >> -- >> 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. _______________________________________________ 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.
