Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 578002 - sys-devel/gcc: unmask USE=sanitize in hardened/linux/amd64
Summary: sys-devel/gcc: unmask USE=sanitize in hardened/linux/amd64
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-22 15:46 UTC by Jonas Jelten
Modified: 2020-05-16 19:32 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
move the sanitize flag unmask from default to arches (profiles.patch,5.23 KB, patch)
2016-03-22 15:55 UTC, Jonas Jelten
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Jelten 2016-03-22 15:46:41 UTC
I'm trying to migrate to hardened profile, but my gcc wants to disable its sanitize flag then.

my current profile default/linux/amd64:

(via portage.settings.profiles)
/var/db/repos/gentoo/profiles/base
/var/db/repos/gentoo/profiles/default/linux
/var/db/repos/gentoo/profiles/arch/base
/var/db/repos/gentoo/profiles/features/multilib
/var/db/repos/gentoo/profiles/features/multilib/lib32
/var/db/repos/gentoo/profiles/arch/amd64
/var/db/repos/gentoo/profiles/default/linux/amd64
/etc/portage/make.profile
/etc/portage/profile

new profile hardened/linux/amd64/selinux:

/var/db/repos/gentoo/profiles/base
/var/db/repos/gentoo/profiles/default/linux
/var/db/repos/gentoo/profiles/arch/base
/var/db/repos/gentoo/profiles/features/multilib
/var/db/repos/gentoo/profiles/features/multilib/lib32
/var/db/repos/gentoo/profiles/arch/amd64
/var/db/repos/gentoo/profiles/releases
/var/db/repos/gentoo/profiles/releases/13.0
/var/db/repos/gentoo/profiles/hardened/linux
/var/db/repos/gentoo/profiles/hardened/linux/amd64
/var/db/repos/gentoo/profiles/features/selinux
/var/db/repos/gentoo/profiles/hardened/linux/amd64/selinux
/etc/portage/make.profile
/etc/portage/profile


default/linux/amd64/package.use.mask enables the gcc sanitize flag, but on the hardened profile, this is missing. It's the same arch, so I suggest moving this flag enabling to arch/amd64 instead of default/linux/amd64.
Comment 1 Jonas Jelten 2016-03-22 15:55:48 UTC
Created attachment 428774 [details, diff]
move the sanitize flag unmask from default to arches

This is the move that fixes it for all archs that support sanitize, even on hardened profile.
Comment 2 Anthony Basile gentoo-dev 2016-03-22 15:58:37 UTC
> 
> default/linux/amd64/package.use.mask enables the gcc sanitize flag, but on
> the hardened profile, this is missing. It's the same arch, so I suggest
> moving this flag enabling to arch/amd64 instead of default/linux/amd64.

sanitize is broken on hardened.
Comment 3 Jonas Jelten 2016-03-22 16:10:56 UTC
Ok. As far as I read in bug 458706, the PaX kernel is the reason asan breaks. I don't plan to use it and instead keep my torvalds-git-kernel. The sanitize should therefore only be or just when using PaX.

-> The gcc ebuild should conflict pax_kernel and sanitize.

At this moment my gcc is rebuilding with +hardened +sanitize.
Comment 4 SpanKY gentoo-dev 2016-03-22 16:33:13 UTC
unmasking it in arch/amd64/ is wrong.  libsanitizer only works for specific targets (arch+OS), not for all OS's.  generally speaking, it only works on linux currently.
Comment 5 Jonas Jelten 2016-03-22 16:37:52 UTC
Ok, my bad then :)
However, most of the PaX features are upstream in Linux anyway, so there's little reason to use hardened-sources.

Where would be the correct unmasking point so all linux profiles supporting sanitize can use it, hardened or not?
Additionally to that, gcc should, if it's still a problem, conflict sanitize with pax_kernel.
Comment 6 Anthony Basile gentoo-dev 2016-03-22 21:51:58 UTC
(In reply to Jonas Jelten from comment #5)
> Ok, my bad then :)
> However, most of the PaX features are upstream in Linux anyway, so there's
> little reason to use hardened-sources.

this is simply false.  in fact, its the different memory layout for processes running under a vanilla kernel versus a pax kernel that causes the problem with executables built with asan.

> 
> Where would be the correct unmasking point so all linux profiles supporting
> sanitize can use it, hardened or not?
> Additionally to that, gcc should, if it's still a problem, conflict sanitize
> with pax_kernel.

i am against unmasking sanitize on the hardened profiles because those profiles are for both hardened userland and kernel.  we support both in tandem.  it would be sufficient to reboot from a vanilla kernel to a pax kernel to break a system where asan has been used widely.  despite the fact that asan should only be used for debugging (not hardening), people will use it to build large portions of their userland.
Comment 7 Anthony Basile gentoo-dev 2016-03-22 22:14:01 UTC
actually Zorry just showed me this link:

http://www.openwall.com/lists/oss-security/2016/02/17/9


looks like asan actually opens up security issues making it very un-hardened. we need to emphasis that asan is for debugging, not hardening.
Comment 8 Jonas Jelten 2016-03-26 16:26:48 UTC
As far as I understood it, the hardened profile doesn't force me to use the "sys-kernel/hardened-sources", and I really hope i'll never be forced to do so.

The "tandem" support is not something I'd endorse and I doubt the hardened team thinks about it that way. If it was required, the hardened profile would mask all other kernel sources, which I think is a really bad idea though.

My use case is that my machine should use sanitize, but only for projects I develop stuff, so _not_ as a default setting. Then, I wanna play around with SELinux, which is available without hardened-sources. So I need the SELinux profile, but I don't want hardened-sources, and still want to use sanitize.

What's the problem with just conflicting the pax kernel with the sanitize flag  in gcc?
Comment 9 Magnus Granberg gentoo-dev 2016-03-26 17:36:40 UTC
(In reply to Jonas Jelten from comment #8)
> As far as I understood it, the hardened profile doesn't force me to use the
> "sys-kernel/hardened-sources", and I really hope i'll never be forced to do
> so.
> 
> The "tandem" support is not something I'd endorse and I doubt the hardened
> team thinks about it that way. If it was required, the hardened profile
> would mask all other kernel sources, which I think is a really bad idea
> though.
> 
> My use case is that my machine should use sanitize, but only for projects I
> develop stuff, so _not_ as a default setting. Then, I wanna play around with
> SELinux, which is available without hardened-sources. So I need the SELinux
> profile, but I don't want hardened-sources, and still want to use sanitize.
> 
> What's the problem with just conflicting the pax kernel with the sanitize
> flag  in gcc?

Way not only use default/linux/amd64/13.0/selinux profile?
We pull in hardened-sources as default and we set pax_kernel and more stuff as default.
Unmasking of sanitize will not happen but if a user want to use it just unmask it.
Comment 10 Jonas Jelten 2016-03-26 17:53:31 UTC
Thanks, I missed that there's a default selinux profile as well. I'll use that instead :)

But still, I think this conflict is pax and gcc specific and the proper and clean solution would be:

* disallow sanitize by default
* allow sanitize for all supported archs for all profiles
* conflict pax_kernel and sanitize in the gcc ebuild

This does not contradict with having some hardened default settings and grants moar freedoms.

But if you think the current solution is the best, I won't argue any more since my particular problem is fixed by your suggestion. Thanks again :)
Comment 11 Anthony Basile gentoo-dev 2016-03-26 18:23:27 UTC
(In reply to Jonas Jelten from comment #8)
> As far as I understood it, the hardened profile doesn't force me to use the
> "sys-kernel/hardened-sources", and I really hope i'll never be forced to do
> so.
> 
> The "tandem" support is not something I'd endorse and I doubt the hardened
> team thinks about it that way. 

we do endorse it and we do think about it that way.

> 
> What's the problem with just conflicting the pax kernel with the sanitize
> flag  in gcc?

comment #6 above
Comment 12 Sergey 'L29Ah' Alirzaev 2020-05-16 19:32:57 UTC
Apply plz.