On 04/27/2011 03:46 PM, Sven Vermeulen wrote: > Hi guys 'n gals, > > Now my question(s): > - Does anyone know of a problem with this approach? > - Does anyone have any objections if I (or someone else) puts this > information in hardened-dev.git (blueness, you did last profile updates > with a staging in hardened-dev.git, but in a separate branch [3], do you > think this approach is needed here as well or can this be put in the > master)? > - And if people have objections, any other ideas on how to tackle the > problem that current SELinux profiles do not support no-multilib (but do > not enable "multilib" USE flag) [4]? > > Wkr, > Sven Vermeulen
You mentioned this approach before and I like it because it is logically clean. The idea is that you take any existing profile and you stack the selinux feature on top of it --- thus "selinuxifying" that it. The only issue I foresee is the typical profile problem, which is that what packages/flags need to be masked/unmasked will depend on what you stack selinux on top of, leading to conflicting requirements. This gives rise to the profile silliness where the same package/use flag is masked then unmasked then remasked etc as you move up through the stack, with increasing customization on the last stacked item, thus making it harder to maintain. Having said that, I think selinux is less susceptible to this problem than other so it may not be bad putting it at the end of the stacking rather than closer to base. The feature should probably be very minimal, dealing only with the unmasking of sec-policy/* from base, masking of >=sec-policy/*-3, and the critical selinux utilities in packages. You can drop a lot of the minimum packages requirements in selinux/packages because 1) they're old and 2) adding more such requirements just makes it harder to maintain. I would not start with the tree. Stage it on the profiles branch of the hardened-dev overlay, then mount --bind on top of profiles to test. You may want to create a separate branch from the current profile branch. Btw, the multilib no-multilib is a lot deeper problem. Here's the stacking on hardened/linux/amd64/no-multilib. Its an example of the mask/unmask/mask as you move up the stack problem: /usr/portage/profiles/base /usr/portage/profiles/default/linux /usr/portage/profiles/arch/base /usr/portage/profiles/features/multilib /usr/portage/profiles/features/multilib/lib32 /usr/portage/profiles/arch/amd64 /usr/portage/profiles/releases /usr/portage/profiles/releases/10.0 /usr/portage/profiles/hardened/linux /usr/portage/profiles/hardened/linux/amd64 /usr/portage/profiles/features/64bit-native /usr/portage/profiles/hardened/linux/amd64/no-multilib So why does this stack include features/multilib??? There you have use.force:multilib use.mask:-multilib which you later have to fix up in features/64bit-native where you have use.force:-multilib use.mask:multilib What a mess! -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
