Mailing List Archive

On 10/22/2013 01:09 PM, Rick "Zero_Chaos" Farina wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/21/2013 03:00 PM, Magnus Granberg wrote:
>> Agenda
>> 1.0 New Devloper
>> 2.0 Toolchain
>> 3.0 Kernel/Grsec/Pax
>> 3.1 Use pax_kernel
> The USE=pax_kernel is used for two reasons. One reason is XYZ needs to
> be done or pax kills the build/test. The second reason is XYZ needs to
> be done to build against a hardened kernel.

It is wrong to build anything against the kernel api except as defined
in /usr/include/linux, hardened or not. We have lots of ebuild which
look at the kernel source tree in /usr/src/linux and build against it.
These are broken. The kernel source tree exposes many internal
structures which are subject to change without notice, not the least of
which afflicted iptables for the longest time.

By extension, no ebuild should build against a hardened kernel source
tree. USE=pax_kernel should never mean "XYZ needs to be done to build
against a hardened kernel". It should only be used to mean "the ELFs
provided by this package *may* be run under a kernel with pax memory
protection enforced." If its a question of an out of source tree
kernel module being built and requiring a patch, eg constification, then
some other solution needs to be found.

What ebuilds are we talking about here that fit the later category?

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA

On 10/22/2013 01:09 PM, Rick "Zero_Chaos" Farina wrote:
>
> 4.0 Selinux
> 5.0 System Integrity
> 6.0 Profile
> I'd like to specifically discuss bringing back the desktop profile by
> user request.
>
>
The old desktop/server/developer profiles were removed for a good
reason. They cannot stack properly given their directory location and
conflicting inheritance requirements. We cannot bring them back as they
were else we will re-introduce the ancient multilib vs non-mutlilib
selinux issue in one manifestation or another.

Nonetheless, I think a desktop profile for hardened is possible along
the lines of what was done for selinux, ie put it in features. Only if
the desktop profile lands at the very bottom of the profile stack will
this work. Alternatively, you can duplicate the desktop profile from
default/linux in hardened/linux and do a simple inheritance from its
parent. This "duplication" would really not be much of a duplication
because there's probably stuff you want to tweak for your own purposes.

I was going to remove those deprecated directories today, but I can hold
off. To be clear, I'm not against a hardened desktop profile, just not
the implementation we had which was broken.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA

On 10/22/2013 02:06 PM, Anthony G. Basile wrote:
> On 10/22/2013 01:09 PM, Rick "Zero_Chaos" Farina wrote:
>>
>> 4.0 Selinux
>> 5.0 System Integrity
>> 6.0 Profile
>> I'd like to specifically discuss bringing back the desktop profile by
>> user request.
>>
>>
> The old desktop/server/developer profiles were removed for a good
> reason. They cannot stack properly given their directory location and
> conflicting inheritance requirements. We cannot bring them back as
> they were else we will re-introduce the ancient multilib vs
> non-mutlilib selinux issue in one manifestation or another.
>
> Nonetheless, I think a desktop profile for hardened is possible along
> the lines of what was done for selinux, ie put it in features. Only
> if the desktop profile lands at the very bottom of the profile stack
> will this work. Alternatively, you can duplicate the desktop profile
> from default/linux in hardened/linux and do a simple inheritance from
> its parent. This "duplication" would really not be much of a
> duplication because there's probably stuff you want to tweak for your
> own purposes.
>
> I was going to remove those deprecated directories today, but I can
> hold off. To be clear, I'm not against a hardened desktop profile,
> just not the implementation we had which was broken.
>
Actually I was wrong in saying "only if it lands at the bottom of the
profile stack" ... That is in fact the 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/eapi-5-files
/usr/portage/profiles/releases/13.0

/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/usr/portage/profiles/targets/desktop
/usr/portage/profiles/hardened/linux/amd64/desktop

So "profiles/targets/desktop" basically trump
"profiles/hardened/linux/amd64" which is the problem: a non-hardened
profile can undo the hardening. We have to get something like this:


/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/eapi-5-files
/usr/portage/profiles/releases/13.0

/usr/portage/profiles/targets/desktop
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA

On 10/22/2013 07:52 PM, Rick "Zero_Chaos" Farina wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/22/2013 02:15 PM, Anthony G. Basile wrote:
>> On 10/22/2013 02:06 PM, Anthony G. Basile wrote:
>>> On 10/22/2013 01:09 PM, Rick "Zero_Chaos" Farina wrote:
>>>> 4.0 Selinux 5.0 System Integrity 6.0 Profile I'd like to
>>>> specifically discuss bringing back the desktop profile by user
>>>> request.
>>>>
>>>>
>>> The old desktop/server/developer profiles were removed for a
>>> good reason. They cannot stack properly given their directory
>>> location and conflicting inheritance requirements. We cannot
>>> bring them back as they were else we will re-introduce the
>>> ancient multilib vs non-mutlilib selinux issue in one
>>> manifestation or another.
>>>
>>> Nonetheless, I think a desktop profile for hardened is possible
>>> along the lines of what was done for selinux, ie put it in
>>> features. Only if the desktop profile lands at the very bottom
>>> of the profile stack will this work. Alternatively, you can
>>> duplicate the desktop profile from default/linux in
>>> hardened/linux and do a simple inheritance from its parent. This
>>> "duplication" would really not be much of a duplication because
>>> there's probably stuff you want to tweak for your own purposes.
>>>
>>> I was going to remove those deprecated directories today, but I
>>> can hold off. To be clear, I'm not against a hardened desktop
>>> profile, just not the implementation we had which was broken.
>>>
>> Actually I was wrong in saying "only if it lands at the bottom of
>> the profile stack" ... That is in fact the 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/eapi-5-files
>> /usr/portage/profiles/releases/13.0
>>
>> /usr/portage/profiles/hardened/linux
>> /usr/portage/profiles/hardened/linux/amd64
>> /usr/portage/profiles/targets/desktop
>> /usr/portage/profiles/hardened/linux/amd64/desktop
>>
>> So "profiles/targets/desktop" basically trump
>> "profiles/hardened/linux/amd64" which is the problem: a
>> non-hardened profile can undo the hardening. We have to get
>> something like this:
>>
>>
>> /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/eapi-5-files
>> /usr/portage/profiles/releases/13.0
>>
>> /usr/portage/profiles/targets/desktop
>> /usr/portage/profiles/hardened/linux
>> /usr/portage/profiles/hardened/linux/amd64
>>
> I was essentially thinking to make a /desktop directory in each
> profile and then parent would be targets/desktop and .. to ensure
> hardened overrides default. Certainly it is not perfect and some
> things from desktop may be lost, but it's a lot better than not having
> a desktop profile at all.
>
> - -Zero

If the parent file has

..
../../../../targets/desktop

then you get the above order with targets/desktop trumping
hardened/amd64 which is bad. If the order is

../../../../targets/desktop
..

then you get and even worse stacking where target/desktop is prior to base.

/usr/portage/profiles/targets/desktop
/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/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/usr/portage/profiles/hardened/linux/amd64/desktop

Because of the way stacking works, you cannot get the desired order by
inheriting both target/desktop and hardened. As I said, we removed
those profiles for a good reason.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA

On 10/22/2013 07:49 PM, Rick "Zero_Chaos" Farina wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/22/2013 01:56 PM, Anthony G. Basile wrote:
>> On 10/22/2013 01:09 PM, Rick "Zero_Chaos" Farina wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 10/21/2013 03:00 PM, Magnus Granberg wrote:
>>>> Agenda
>>>> 1.0 New Devloper
>>>> 2.0 Toolchain
>>>> 3.0 Kernel/Grsec/Pax
>>>> 3.1 Use pax_kernel
>>> The USE=pax_kernel is used for two reasons. One reason is XYZ needs to
>>> be done or pax kills the build/test. The second reason is XYZ needs to
>>> be done to build against a hardened kernel.
>> It is wrong to build anything against the kernel api except as defined
>> in /usr/include/linux, hardened or not. We have lots of ebuild which
>> look at the kernel source tree in /usr/src/linux and build against it.
>> These are broken. The kernel source tree exposes many internal
>> structures which are subject to change without notice, not the least of
>> which afflicted iptables for the longest time.
>>
>> By extension, no ebuild should build against a hardened kernel source
>> tree. USE=pax_kernel should never mean "XYZ needs to be done to build
>> against a hardened kernel". It should only be used to mean "the ELFs
>> provided by this package *may* be run under a kernel with pax memory
>> protection enforced." If its a question of an out of source tree
>> kernel module being built and requiring a patch, eg constification, then
>> some other solution needs to be found.
>>
>> What ebuilds are we talking about here that fit the later category?
>>
> Kernel modules such as nvidia-drivers, which I'm confident are allowed
> to build against the kernel sources.
>
> - -Zero
>

Out of source tree kernel modules can (and often must) build against
/usr/src/linux. My comments were about userland.

Anyhow, back to the original issue, can't some local use flag be used
here to say apply the constify patch? We don't want to polute the
meaning of USE=pax_kernel.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA