FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 10-23-2011, 06:00 PM
"Paweł Hajdan, Jr."
 
Default Building hardened gcc specs always, just not enabling them by default

Looks like the thread I started about moving more hardened features to
default
<http://archives.gentoo.org/gentoo-dev/msg_ef3dbd4ba400a5936cd5b7546b86d875.xml>
got a lot of positive feedback. Kernel hardening features are more
problematic, but hardening the toolchain seems to be within reach.

I'd like to produce some implementation plan for that, and my suggestion
is to change the meaning of the "hardened" USE flag for GCC. I'd like to
build all 4 or so specs for gcc always, and the "hardened" USE flag
would just control which one is the default: the vanilla one or
full-hardening one.

This would allow people to manually start using hardened toolchain
without even switching profile, and should be a no-op for everyone else.
From there we can later proceed to apply more features.

Thoughts?
 
Old 10-23-2011, 07:03 PM
"Anthony G. Basile"
 
Default Building hardened gcc specs always, just not enabling them by default

On 10/23/2011 02:00 PM, "Paweł Hajdan, Jr." wrote:
> Looks like the thread I started about moving more hardened features to
> default
> <http://archives.gentoo.org/gentoo-dev/msg_ef3dbd4ba400a5936cd5b7546b86d875.xml>
> got a lot of positive feedback. Kernel hardening features are more
> problematic, but hardening the toolchain seems to be within reach.
>
> I'd like to produce some implementation plan for that, and my suggestion
> is to change the meaning of the "hardened" USE flag for GCC. I'd like to
> build all 4 or so specs for gcc always, and the "hardened" USE flag
> would just control which one is the default: the vanilla one or
> full-hardening one.
>
> This would allow people to manually start using hardened toolchain
> without even switching profile, and should be a no-op for everyone else.
> From there we can later proceed to apply more features.
>
> Thoughts?
>
Where would the hardened profiles fit in this? This requires some
thought. Right now "hardened" means three choices: 1) hardened
toolchain, 2) hardened-sources kernel, 3) hardened profile. Some
packages are masked or added to the profile for the toolchain, some for
the kernel. We'd have to disentangle those. I'm not sure how the
details would play out.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
 
Old 10-23-2011, 07:20 PM
Alexandre Rostovtsev
 
Default Building hardened gcc specs always, just not enabling them by default

On Sun, Oct 23, 2011 at 3:03 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> Where would the hardened profiles fit in this? * This requires some
> thought. *Right now "hardened" means three choices: 1) hardened
> toolchain, 2) hardened-sources kernel, 3) hardened profile. *Some
> packages are masked or added to the profile for the toolchain, some for
> the kernel. *We'd have to disentangle those. *I'm not sure how the
> details would play out.

My impression was that for the hardened kernels case, specific USE
flags such as "pax_kernel" are supposed to be used instead of the
generic "hardened".

-Alexandre
 
Old 10-23-2011, 07:47 PM
"Anthony G. Basile"
 
Default Building hardened gcc specs always, just not enabling them by default

On 10/23/2011 03:20 PM, Alexandre Rostovtsev wrote:
> On Sun, Oct 23, 2011 at 3:03 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> Where would the hardened profiles fit in this? This requires some
>> thought. Right now "hardened" means three choices: 1) hardened
>> toolchain, 2) hardened-sources kernel, 3) hardened profile. Some
>> packages are masked or added to the profile for the toolchain, some for
>> the kernel. We'd have to disentangle those. I'm not sure how the
>> details would play out.
> My impression was that for the hardened kernels case, specific USE
> flags such as "pax_kernel" are supposed to be used instead of the
> generic "hardened".
>
> -Alexandre
>
Yes. Because some people wanted binaries built with a vanilla toolchain
running under a pax kernel. So, we encouraged the use of a different
USE flag to tell ebuilds that this package *might* be run under a
pax_kernel and therefore should have certain pax markings. Since that
has nothing to do with a hardened toolchain, we encouraged the use of a
new local flag, pax_kernel. However, this is a weak USE flag because
pax marking a binary that runs under a vanilla kernel is harmless, as
the kernel will simply ignore the pt_pax program header in the ELF. And
all binaries built in gentoo have this header automatically because of a
patch in binutils. Its added "just in case". You can see it when you
do readelf -l /path/to/elf.

So if you look in the hardened profiles, you'll see some things masked
like net-im/skype because of the kernel, and some things masked like
=sys-devel/gdb-7.0* because of the toolchain. If the hardened toolchain
moves into mainstream, then we'll have to sort through those and figure
out how to incorporate them into the main profiles. How would we say,
if you use gcc-config and choose gcc-4.5.1-hardened spec, mask
gdb-7.0*? I don't think its impossible, but I'm not seeing how to
proceed right now.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
 
Old 10-24-2011, 06:58 AM
"Paweł Hajdan, Jr."
 
Default Building hardened gcc specs always, just not enabling them by default

On 10/23/11 9:47 PM, Anthony G. Basile wrote:
> So if you look in the hardened profiles, you'll see some things masked
> like net-im/skype because of the kernel, and some things masked like
> =sys-devel/gdb-7.0* because of the toolchain. If the hardened toolchain
> moves into mainstream, then we'll have to sort through those and figure
> out how to incorporate them into the main profiles.

That's right. My goal now is to come up with a realistic plan how to do
that. It seems most people agree it's a good goal, now we'd need to
identify possible problems and find solutions.

Thank you for helping identify problems. Please take a look to see if my
suggestions make sense.

> How would we say,
> if you use gcc-config and choose gcc-4.5.1-hardened spec, mask
> gdb-7.0*? I don't think its impossible, but I'm not seeing how to
> proceed right now.

First, I'd like the hardened spec to be non-default, so that if the user
chooses the hardened spec he'd be "on his own", and expect possibly more
breakages.

Second, profiles/hardened/package.mask seems to contain only few
entries, and a more recent gdb than 7.0 works and is in stable. I've
checked on my hardened system. This doesn't seem to be a serious issue,
maybe we can just punt gdb 7.0 or print a message that it's expected to
be broken with hardened spec.

Third - can we forcefully disable hardened features in packages that are
not compatible? My assumption is yes, and we should probably print a
warning then.

Fourth - we can add the gcc spec to emerge --info.

What do you think?
 
Old 10-24-2011, 08:49 AM
Duncan
 
Default Building hardened gcc specs always, just not enabling them by default

Paweł Hajdan, Jr. posted on Mon, 24 Oct 2011 08:58:57 +0200 as excerpted:

> Third - can we forcefully disable hardened features in packages that are
> not compatible? My assumption is yes, and we should probably print a
> warning then.

If a warning is to be printed (and I agree that's a good idea), please
arrange for it to be disableable per-package (perhaps via environmental
variable setting, WARN_DISABLE_HARDENED or the like).

That way, either the PM can implement a package.hardened-warn or
whatever, or (for portage at least) the user can arrange for the same
effect via /etc/portage/env/*/* files.

The idea would be that the user can accumulate an easily checked list of
packages he knows about and doesn't want to be bothered by the hardened-
disable warnings for, while he still gets visible warnings for packages
not on that list (and thus presumably that he's not yet aware of) that
disable whatever hardening feature.

Or just make it a USE flag on the packages it applies to: hardened-warn
or the like, which use-defaults to ON.

Either way, an eclass to standardize things sounds very useful.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 10-24-2011, 10:58 AM
"Anthony G. Basile"
 
Default Building hardened gcc specs always, just not enabling them by default

On 10/24/2011 02:58 AM, "Paweł Hajdan, Jr." wrote:
>
>> How would we say,
>> if you use gcc-config and choose gcc-4.5.1-hardened spec, mask
>> gdb-7.0*? I don't think its impossible, but I'm not seeing how to
>> proceed right now.
> First, I'd like the hardened spec to be non-default, so that if the user
> chooses the hardened spec he'd be "on his own", and expect possibly more
> breakages.
Well not totally on their own, they'd report it and we'd have to see
what we want to do on an ad hoc basis. So maybe the first step would be
to just build 5 specs:

[1] x86_64-pc-linux-gnu-4.4.5
[2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
[3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
[4] x86_64-pc-linux-gnu-4.4.5-hardenednossp
[5] x86_64-pc-linux-gnu-4.4.5-vanilla

Here [1] = fully hardened. Then ship with no other changes. When bug
start to come in, you can deal with each --- some may be fixes at the
package level (usually the build system), some may be ebuild fixes, some
may need to go into the profiles.

There is one other catch Zorry pointed out, glibc. There are some
patches against glibc which would have to go in unconditionally. Take a
look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently
they're if use hardened. That conditional would be removed.

> Second, profiles/hardened/package.mask seems to contain only few
> entries, and a more recent gdb than 7.0 works and is in stable. I've
> checked on my hardened system. This doesn't seem to be a serious issue,
> maybe we can just punt gdb 7.0 or print a message that it's expected to
> be broken with hardened spec.

Those profiles have some ancient stuff in them which we know about, but
haven't removed for legacy reasons. You want to look at the files under
profiles/hardened/linux/ What would wind up happening if hardened goes
mainstream is that those profiles would be reduced to just the
maskings/unmaskings for a pax hardened kernel. Selinux has its own.

> Third - can we forcefully disable hardened features in packages that are
> not compatible? My assumption is yes, and we should probably print a
> warning then.

There are a few things you can do here, yes. It is always possible to
turn off hardening because the *last* resort solution is just switch
compile specs in the ebuild. This is only if none of the other methods
work, the best method being fix the build system so you can switch the
feature off in configure. I had to use it once for virtualbox which has
a brain dead build system. There we warn the user to switch specs in
pkg_setup() using ... if built_with_use sys-devel/gcc hardened.


> Fourth - we can add the gcc spec to emerge --info.
>
> What do you think?
>
Good idea.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
 
Old 10-24-2011, 11:26 AM
"Paweł Hajdan, Jr."
 
Default Building hardened gcc specs always, just not enabling them by default

On 10/24/11 12:58 PM, Anthony G. Basile wrote:
> Well not totally on their own, they'd report it and we'd have to see
> what we want to do on an ad hoc basis.

Fair enough, that's why I suggested to make the hardened spec
non-default, so that they have to switch it, and include the info in
emerge --info so we can identify the reason.

> So maybe the first step would be
> to just build 5 specs:
>
> [1] x86_64-pc-linux-gnu-4.4.5
> [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
> [3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
> [4] x86_64-pc-linux-gnu-4.4.5-hardenednossp
> [5] x86_64-pc-linux-gnu-4.4.5-vanilla
>
> Here [1] = fully hardened. Then ship with no other changes. When bug
> start to come in, you can deal with each --- some may be fixes at the
> package level (usually the build system), some may be ebuild fixes, some
> may need to go into the profiles.

Right, this is exactly what I'm suggesting, just make [5] the default or
do some juggling so that [1] is vanilla and [5] is fully hardened or
something like that.

> There is one other catch Zorry pointed out, glibc. There are some
> patches against glibc which would have to go in unconditionally. Take a
> look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently
> they're if use hardened. That conditional would be removed.

Ah, ok. So we have another one. Let's find out our exact constraints:

1. Are those glibc patches required for gcc built with hardened support?
Will the gcc build fail without them, or will things fail at runtime
without them?

2. Enabling glibc patches would mean enabling PIC by default, right? Is
that OK? Can it cause breakages?

3. Am I reading things correctly that PIE is _not_ enabled by default,
but only when _using_ (i.e. active, not just built) PIE-enabled gcc specs?

> Those profiles have some ancient stuff in them which we know about, but
> haven't removed for legacy reasons.

Please note I've checked on my hardened system and the file I cited has
been used and provided as the mask reason. Maybe it's ancient, but it's
still in use.

> You want to look at the files under
> profiles/hardened/linux/ What would wind up happening if hardened goes
> mainstream is that those profiles would be reduced to just the
> maskings/unmaskings for a pax hardened kernel. Selinux has its own.

Sounds good. By the way, if you're concerned about masking things and so
on - why are hardened-sources _not_ masked on non-hardened profiles?

There are two ways to get an invalid mix of hardened kernel and
incompatible packages:

a) hardened profile + trying to emerge incompatible packages (this is
currently blocked by p.mask entries)

b) normal profile + incompatible packages + hardened-sources (not blocked)

>> Third - can we forcefully disable hardened features in packages that are
>> not compatible? My assumption is yes, and we should probably print a
>> warning then.
>
> There are a few things you can do here, yes. It is always possible to
> turn off hardening because the *last* resort solution is just switch
> compile specs in the ebuild.

Do you mean calling gcc-config here or something else? If gcc-config,
it'd be quite hacky and fragile (parallel building of multiple packages,
having multiple versions of gcc installed).

Is it possible to just pass flags to GCC: disable all this hardened
stuff? I know you can disable stack protector, but how about PIE or PIC,
and possible other hardening features?

> This is only if none of the other methods
> work, the best method being fix the build system so you can switch the
> feature off in configure. I had to use it once for virtualbox which has
> a brain dead build system. There we warn the user to switch specs in
> pkg_setup() using ... if built_with_use sys-devel/gcc hardened.

Ah, so it tells the user to switch gcc profile and dies. :-/

Well, in my opinion we could get rid of virtualbox anyway (p.mask it
everywhere), I think it has been tainted in the kernel as crap.
<https://lkml.org/lkml/2011/10/6/317>
 
Old 10-24-2011, 01:04 PM
Francesco Riosa
 
Default Building hardened gcc specs always, just not enabling them by default

[...]
>
> Well, in my opinion we could get rid of virtualbox anyway (p.mask it
> everywhere), I think it has been tainted in the kernel as crap.
> <https://lkml.org/lkml/2011/10/6/317>
>
<troll>
please do the same for x11-drivers/nvidia-drivers and x11-drivers/ati-drivers
</troll>
 
Old 10-25-2011, 05:59 AM
Ryan Hill
 
Default Building hardened gcc specs always, just not enabling them by default

On Mon, 24 Oct 2011 13:26:01 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 10/24/11 12:58 PM, Anthony G. Basile wrote:
> > Well not totally on their own, they'd report it and we'd have to see
> > what we want to do on an ad hoc basis.
>
> Fair enough, that's why I suggested to make the hardened spec
> non-default, so that they have to switch it, and include the info in
> emerge --info so we can identify the reason.
>
> > So maybe the first step would be
> > to just build 5 specs:
> >
> > [1] x86_64-pc-linux-gnu-4.4.5
> > [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
> > [3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
> > [4] x86_64-pc-linux-gnu-4.4.5-hardenednossp
> > [5] x86_64-pc-linux-gnu-4.4.5-vanilla
> >
> > Here [1] = fully hardened. Then ship with no other changes. When bug
> > start to come in, you can deal with each --- some may be fixes at the
> > package level (usually the build system), some may be ebuild fixes, some
> > may need to go into the profiles.
>
> Right, this is exactly what I'm suggesting, just make [5] the default or
> do some juggling so that [1] is vanilla and [5] is fully hardened or
> something like that.

I would expect x86_64-pc-linux-gnu-4.4.5 to be the vanilla profile and the
fully hardened one to be something like x86_64-pc-linux-gnu-4.4.5-hardened.

> > There is one other catch Zorry pointed out, glibc. There are some
> > patches against glibc which would have to go in unconditionally. Take a
> > look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently
> > they're if use hardened. That conditional would be removed.
>
> Ah, ok. So we have another one. Let's find out our exact constraints:
>
> 1. Are those glibc patches required for gcc built with hardened support?
> Will the gcc build fail without them, or will things fail at runtime
> without them?
>
> 2. Enabling glibc patches would mean enabling PIC by default, right? Is
> that OK? Can it cause breakages?
>
> 3. Am I reading things correctly that PIE is _not_ enabled by default,
> but only when _using_ (i.e. active, not just built) PIE-enabled gcc specs?

I imagine they're conditional for a reason. I just don't know what that
reason is myself.

> >> Third - can we forcefully disable hardened features in packages that are
> >> not compatible? My assumption is yes, and we should probably print a
> >> warning then.
> >
> > There are a few things you can do here, yes. It is always possible to
> > turn off hardening because the *last* resort solution is just switch
> > compile specs in the ebuild.
>
> Do you mean calling gcc-config here or something else? If gcc-config,
> it'd be quite hacky and fragile (parallel building of multiple packages,
> having multiple versions of gcc installed).
>
> Is it possible to just pass flags to GCC: disable all this hardened
> stuff? I know you can disable stack protector, but how about PIE or PIC,
> and possible other hardening features?

You might be able to use the GCC_SPECS env var.

Personally I think this is a lot of work for not much benefit, but if you
want to do it then who am I to argue.


--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 

Thread Tools




All times are GMT. The time now is 05:01 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org