| 1 |
On 04/27/2011 03:46 PM, Sven Vermeulen wrote: |
| 2 |
> Hi guys 'n gals, |
| 3 |
> |
| 4 |
|
| 5 |
> Now my question(s): |
| 6 |
> - Does anyone know of a problem with this approach? |
| 7 |
> - Does anyone have any objections if I (or someone else) puts this |
| 8 |
> information in hardened-dev.git (blueness, you did last profile updates |
| 9 |
> with a staging in hardened-dev.git, but in a separate branch [3], do you |
| 10 |
> think this approach is needed here as well or can this be put in the |
| 11 |
> master)? |
| 12 |
> - And if people have objections, any other ideas on how to tackle the |
| 13 |
> problem that current SELinux profiles do not support no-multilib (but do |
| 14 |
> not enable "multilib" USE flag) [4]? |
| 15 |
> |
| 16 |
> Wkr, |
| 17 |
> Sven Vermeulen |
| 18 |
|
| 19 |
You mentioned this approach before and I like it because it is logically |
| 20 |
clean. The idea is that you take any existing profile and you stack the |
| 21 |
selinux feature on top of it --- thus "selinuxifying" that it. |
| 22 |
|
| 23 |
The only issue I foresee is the typical profile problem, which is that |
| 24 |
what packages/flags need to be masked/unmasked will depend on what you |
| 25 |
stack selinux on top of, leading to conflicting requirements. This |
| 26 |
gives rise to the profile silliness where the same package/use flag is |
| 27 |
masked then unmasked then remasked etc as you move up through the stack, |
| 28 |
with increasing customization on the last stacked item, thus making it |
| 29 |
harder to maintain. |
| 30 |
|
| 31 |
Having said that, I think selinux is less susceptible to this problem |
| 32 |
than other so it may not be bad putting it at the end of the stacking |
| 33 |
rather than closer to base. |
| 34 |
|
| 35 |
The feature should probably be very minimal, dealing only with the |
| 36 |
unmasking of sec-policy/* from base, masking of >=sec-policy/*-3, and |
| 37 |
the critical selinux utilities in packages. You can drop a lot of the |
| 38 |
minimum packages requirements in selinux/packages because 1) they're old |
| 39 |
and 2) adding more such requirements just makes it harder to maintain. |
| 40 |
|
| 41 |
I would not start with the tree. Stage it on the profiles branch of the |
| 42 |
hardened-dev overlay, then mount --bind on top of profiles to test. You |
| 43 |
may want to create a separate branch from the current profile branch. |
| 44 |
|
| 45 |
Btw, the multilib no-multilib is a lot deeper problem. Here's the |
| 46 |
stacking on hardened/linux/amd64/no-multilib. Its an example of the |
| 47 |
mask/unmask/mask as you move up the stack problem: |
| 48 |
|
| 49 |
/usr/portage/profiles/base |
| 50 |
/usr/portage/profiles/default/linux |
| 51 |
/usr/portage/profiles/arch/base |
| 52 |
/usr/portage/profiles/features/multilib |
| 53 |
/usr/portage/profiles/features/multilib/lib32 |
| 54 |
/usr/portage/profiles/arch/amd64 |
| 55 |
/usr/portage/profiles/releases |
| 56 |
/usr/portage/profiles/releases/10.0 |
| 57 |
/usr/portage/profiles/hardened/linux |
| 58 |
/usr/portage/profiles/hardened/linux/amd64 |
| 59 |
/usr/portage/profiles/features/64bit-native |
| 60 |
/usr/portage/profiles/hardened/linux/amd64/no-multilib |
| 61 |
|
| 62 |
|
| 63 |
So why does this stack include features/multilib??? There you have |
| 64 |
|
| 65 |
use.force:multilib |
| 66 |
use.mask:-multilib |
| 67 |
|
| 68 |
which you later have to fix up in features/64bit-native where you have |
| 69 |
|
| 70 |
use.force:-multilib |
| 71 |
use.mask:multilib |
| 72 |
|
| 73 |
|
| 74 |
What a mess! |
| 75 |
|
| 76 |
|
| 77 |
-- |
| 78 |
Anthony G. Basile, Ph.D. |
| 79 |
Gentoo Linux Developer [Hardened] |
| 80 |
E-Mail : blueness@g.o |
| 81 |
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 |
| 82 |
GnuPG ID : D0455535 |
Archives