On Fri, Mar 18, 2011 at 07:41:37AM -0400, Anthony G. Basile wrote:
> Hi Sven,
>
> Did you identify what the wierdness was. I'd like to eventually clean
> up the profiles. Rather than
[...]
> I'd like the selinux to conform to the hardened/linux/amd64, ie change
> 10-16 to just
>
> selinux/v2refpolicy/amd64
> selinux/v2refpolicy/amd64/no-multilib
>
> The /desktop /developer /server would not be deprecated, but present
> silently as they are for hardened/linux/amd64.

No.

Beneith is the current "inheritance" of the profile (using the "parent"
file and using the same order as presented in the file).

selinux/v2refpolicy/amd64/hardened
`- selinux/v2refpolicy/amd64
+- default/linux/amd64
| +- base
| +- default/linux
| '- arch/amd64
`- selinux/v2refpolicy
`- selinux
`- base

"base" and "selinux" both have use.mask on "multilib". So one would
imagine that the current profile does /not/ allow multilib (you are
not allowed to set the "multilib" USE flag). There's no profile that
has a use.force on multilib.

Or I could be completely wrong in this small analysis.

I'm no profile/portage wizard though. Anyone up to the challenge?

Wkr,
Sven Vermeulen

On 03/18/2011 11:43 AM, Sven Vermeulen wrote:
> On Fri, Mar 18, 2011 at 07:41:37AM -0400, Anthony G. Basile wrote:
>> Hi Sven,
>>
>> Did you identify what the wierdness was. I'd like to eventually clean
>> up the profiles. Rather than
> [...]
>> I'd like the selinux to conform to the hardened/linux/amd64, ie change
>> 10-16 to just
>>
>> selinux/v2refpolicy/amd64
>> selinux/v2refpolicy/amd64/no-multilib
>>
>> The /desktop /developer /server would not be deprecated, but present
>> silently as they are for hardened/linux/amd64.
>
> No.
>
> Beneith is the current "inheritance" of the profile (using the "parent"
> file and using the same order as presented in the file).
>
> selinux/v2refpolicy/amd64/hardened
> `- selinux/v2refpolicy/amd64
> +- default/linux/amd64
> | +- base
> | +- default/linux
> | '- arch/amd64
> `- selinux/v2refpolicy
> `- selinux
> `- base
>
> "base" and "selinux" both have use.mask on "multilib". So one would
> imagine that the current profile does /not/ allow multilib (you are
> not allowed to set the "multilib" USE flag). There's no profile that
> has a use.force on multilib.
>
> Or I could be completely wrong in this small analysis.
>
> I'm no profile/portage wizard though. Anyone up to the challenge?
>
> Wkr,
> Sven Vermeulen

You're not wrong, but this can be restructured to come better in line
with the rest of the hardened profiles. I have to do a careful analysis
of the stacking and see if we can get something similar out of simpler
stackings and then fix up what might be missed in the final layers of
the stack.

This is still far off. First stabilization.

--
Anthony G. Basile, Ph.D.
Gentoo Developer

On Fri, Mar 18, 2011 at 06:55:34PM -0400, Anthony G. Basile wrote:
> You're not wrong, but this can be restructured to come better in line
> with the rest of the hardened profiles. I have to do a careful analysis
> of the stacking and see if we can get something similar out of simpler
> stackings and then fix up what might be missed in the final layers of
> the stack.

My suggestion would be to

1. stabilize the current set of policies
2. remove the policies whose version is >= 3.0 (including those -2008* ones)
3. make a "features/selinux" profile (which contains all SELinux relevant
aspects but is not a real profile in its own)
4. Create sublocations within the existing profiles for SELinux (like
hardened/linux/amd64/selinux and hardened/linux/amd64/no-multilib/selinux)

These sublocations would only have a single file called "parent" showing
something like:
../
../../../../features/selinux

I just tried this on my no-multilib system as well as on a multilib one, and
apart from USE="gdbm bzip2 urandom nptl justify -fortran" I have had no
other changes (checked the different outputs of "emerge --info" as well as a
"emerge -puDN world").

Wkr,
Sven Vermeulen

On 03/27/2011 03:42 PM, Sven Vermeulen wrote:
> On Fri, Mar 18, 2011 at 06:55:34PM -0400, Anthony G. Basile wrote:
>> You're not wrong, but this can be restructured to come better in line
>> with the rest of the hardened profiles. I have to do a careful analysis
>> of the stacking and see if we can get something similar out of simpler
>> stackings and then fix up what might be missed in the final layers of
>> the stack.
>
> My suggestion would be to
>
> 1. stabilize the current set of policies
> 2. remove the policies whose version is >= 3.0 (including those -2008* ones)
> 3. make a "features/selinux" profile (which contains all SELinux relevant
> aspects but is not a real profile in its own)
> 4. Create sublocations within the existing profiles for SELinux (like
> hardened/linux/amd64/selinux and hardened/linux/amd64/no-multilib/selinux)
>
> These sublocations would only have a single file called "parent" showing
> something like:
> ../
> ../../../../features/selinux
>
> I just tried this on my no-multilib system as well as on a multilib one, and
> apart from USE="gdbm bzip2 urandom nptl justify -fortran" I have had no
> other changes (checked the different outputs of "emerge --info" as well as a
> "emerge -puDN world").
>
> Wkr,
> Sven Vermeulen


I agree with this plan. I really like step 4.

--
Anthony G. Basile, Ph.D.
Gentoo Developer