Re: [gentoo-dev] Moving more hardening features to default?
W dniu 20.10.2011 10:47, Paweł Hajdan, Jr. pisze: I've noticed http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags, i.e. Debian is starting to make more and more hardening features default, at least for most packages. Should we start doing that too? What are possible problems with that? It seems like it's mostly about USE=hardened, right? Hi, just a bunch of quick questions from a hardened newbie: 1) Is there are reason to do it beside Debian is going to do it? 2) What's wrong with current approach i.e. having seperate hardened profile? 3) What are the benefits for an average desktop user or high-performance cluster? While answering that, please skip things obvious like having more secure box. Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving more hardening features to default?
On 10/25/11 16:18, Kacper Kowalik wrote: W dniu 20.10.2011 10:47, Paweł Hajdan, Jr. pisze: I've noticed http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags, i.e. Debian is starting to make more and more hardening features default, at least for most packages. Should we start doing that too? What are possible problems with that? It seems like it's mostly about USE=hardened, right? Hi, just a bunch of quick questions from a hardened newbie: 1) Is there are reason to do it beside Debian is going to do it? For most users it has no negative impact. So in terms of cost it is, analogous to as-needed, a little bit more work for us as maintainers. On the upside we get the more secure thing you don't care about. And you can still turn it all off, so you have no mandatory changes (except configuration defaults) 2) What's wrong with current approach i.e. having seperate hardened profile? Nothing wrong per se, but it would be beneficial to make these paranoia features more available to users. You can still turn 'em all off, if you want, so we're basically only suggesting to go from an opt-in to an opt-out for those features. 3) What are the benefits for an average desktop user or high-performance cluster? While answering that, please skip things obvious like having more secure box. From that perspective none, but for those of us that do other things (like running public-facing servers) it lets us sleep a bit better at night. Counter-question would be what's the downside - I've seen no benchmarks that show a serious performance impact for most features (last time I looked most of the PaX kernel features are 1% runtime cost)
Re: [gentoo-dev] Moving more hardening features to default?
On Tue, Oct 25, 2011 at 10:18 AM, Kacper Kowalik xarthis...@gentoo.org wrote: 2) What's wrong with current approach i.e. having seperate hardened profile? I don't really see the hardened profile and some hardening by default as being redundant. When I think about the hardened profile I think high security at the cost of software compatibility. If you're running a virtual webhosting company you probably don't care that mplayer doesn't work on your virtual hosts but you do care that some zero-day exploit could let somebody escape from their sandbox. The default configuration should aim for a reasonable balance of security and convenience. We still fix or mask known security issues, and we still do stuff like not shipping lots of stuff listening on ports by default. If adding something to CFLAGS makes systems more secure with minimal compatibility or performance problems, then there is no reason not to do it. And Debian is doing it or whatever isn't actually a bad reason to consider this. When Debian does something by default, it means that upstream packages will take notice. In fact, you could even see something that today would be strange like having upstream mark a bug report invalid because you DIDN'T have stack protection enabled or whatever. Doing things that are dumb just because others are doing it isn't a good thing, but just being different for the sake of being different isn't either. Rich
Re: [gentoo-dev] Moving more hardening features to default?
On 10/25/11 5:11 PM, Rich Freeman wrote: And Debian is doing it or whatever isn't actually a bad reason to consider this. When Debian does something by default, it means that upstream packages will take notice. Right, I was thinking about the change for a long time, but if Debian, which advertises itself as stable and well-tested, thinks it's time to do it, then why should we stay behind? My primary motivation is doing the right thing, and linking to Debian's plans is one of my points to show that it makes sense. I think that generally just trying to patch detected vulnerabilities as soon as possible is not sufficient to stay reasonably secure. Mitigation techniques like SSP and ASLR are really important, because they give you more time to fix vulnerabilities (by making it harder to exploit them). And again, I don't suggest enabling anything by default that would degrade performance in an unacceptable way or create compatibility problems that can't be solved. And I'm also looking for a way that will provide a seamless upgrade path for existing users (i.e. one that doesn't break them). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving more hardening features to default?
On 10/20/2011 04:47 AM, Paweł Hajdan, Jr. wrote: I've noticed http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags, i.e. Debian is starting to make more and more hardening features default, at least for most packages. Should we start doing that too? What are possible problems with that? It seems like it's mostly about USE=hardened, right? I've noticed that several binary drivers like nvidia-drivers are masked on hardened - is it a problem with hardened-sources, or with hardened toolchain? The nvidia-driver problem is due to PaX in the kernel, so its hardened-sources. USE=hardened refers to only toolchain hardening. The problems there are mostly packages which break with PIE because they (ab)use assembly. Things like virtualbox and some codecs. This can become a thorny mess. It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2 and ssp into mainstream though. Packages which break because of either of those two features are broken and should be fixed anyhow. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Moving more hardening features to default?
2011/10/20 Anthony G. Basile bluen...@gentoo.org: USE=hardened refers to only toolchain hardening. The problems there are mostly packages which break with PIE because they (ab)use assembly. Things like virtualbox and some codecs. This can become a thorny mess. It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2 and ssp into mainstream though. Packages which break because of either of those two features are broken and should be fixed anyhow. This sounds like good idea to do so, I would say that most hardened features should be merged to to main profile as soon as they won't cause major PITA for the regular users. Cheers Tom
Re: [gentoo-dev] Moving more hardening features to default?
2011/10/20 Tomáš Chvátal scarab...@gentoo.org: I would say that most hardened features should be merged to to main profile as soon as they won't cause major PITA for the regular users. I agree - especially for stuff that doesn't require active setup (stack protection, PaX, etc). If there are features that we could turn on but for a few packages, maybe the solution there is to discuss them on-list and target them for future adoption and make an effort to fix the impacted ebuilds. Fix could mean either making the package work with the hardened feature, or disabling it just for that package (filter-flags, tag binaries not to run with features, etc). The hardened profile can still of course be the place where we push the envelope at the cost of more packages being masked, and there will always be things like MAC that represent a big change in how a system is run that will take a long time to become mainstream. Rich
Re: [gentoo-dev] Moving more hardening features to default?
On Thursday 20 October 2011 04:47:14 Paweł Hajdan, Jr. wrote: I've noticed http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags, i.e. Debian is starting to make more and more hardening features default, at least for most packages. seems a bit light on what actually is being used random thoughts: - we've long defaulted to linking with relro - defaulting to bindnow is pretty much a no go for USE=-hardened - building everything as PIC/PIE comes with performance penalty for some architectures (e.g. x86), and is often the source of build issues with the hardened port - we've long defaulted to building with _FORTIFY_SOURCE - i'd need to see actual overhead data with SSP to see about enabling it by default -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Moving more hardening features to default?
On Thursday 20 October 2011 08:41:55 Rich Freeman wrote: 2011/10/20 Tomáš Chvátal: I would say that most hardened features should be merged to to main profile as soon as they won't cause major PITA for the regular users. I agree - especially for stuff that doesn't require active setup (stack protection, PaX, etc). except PaX requires kernel patches and is known to break things. not an acceptable default. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Moving more hardening features to default?
On 10/20/2011 08:57 AM, Mike Frysinger wrote: On Thursday 20 October 2011 08:41:55 Rich Freeman wrote: 2011/10/20 Tomáš Chvátal: I would say that most hardened features should be merged to to main profile as soon as they won't cause major PITA for the regular users. I agree - especially for stuff that doesn't require active setup (stack protection, PaX, etc). except PaX requires kernel patches and is known to break things. not an acceptable default. -mike I would not recommend PaX at this time. As Mike said, it breaks things, sometimes important things. Eg. python ctypes was broken there for a while on hardened. Also, unlike toolchain, it requires that you configure your kernel correctly, ie have familiarity with what works and what doesn't under certain PaX features. This may be trivial for us, but might be more than we want to put newbies through. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Moving more hardening features to default?
On Thu, Oct 20, 2011 at 10:36 AM, Anthony G. Basile bluen...@gentoo.org wrote: I would not recommend PaX at this time. As Mike said, it breaks things, sometimes important things. Eg. python ctypes was broken there for a while on hardened. Also, unlike toolchain, it requires that you configure your kernel correctly, ie have familiarity with what works and what doesn't under certain PaX features. This may be trivial for us, but might be more than we want to put newbies through. I used it as an example because it is passive for the most part, and I think most of the configuration could be handled by the ebuilds. However, I didn't mean to suggest that it was ready to be made a default. If the list of broken packages were small enough I think that it would be fair to consider it as a future default to work towards. I was trying to draw a contrast between passive things like stack-protection and things that really get in your face like MAC. Rich
Re: [gentoo-dev] Moving more hardening features to default?
On Thursday 20 October 2011 12:47:27 Rich Freeman wrote: I was trying to draw a contrast between passive things like stack-protection and things that really get in your face like MAC. the trouble was in the context quoting then ... it sounded like you were proposing PaX by default i am a fan of things that just work though which is why i was happy to merge the fortify source code. most of that checking is done at compile time, so the runtime overhead is generally small. and in terms of packages that did break, it was (more often than not) because they were broken already but we never noticed. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Moving more hardening features to default?
torsdag 20 oktober 2011 13.17.33 skrev Mike Frysinger: On Thursday 20 October 2011 12:47:27 Rich Freeman wrote: I was trying to draw a contrast between passive things like stack-protection and things that really get in your face like MAC. the trouble was in the context quoting then ... it sounded like you were proposing PaX by default i am a fan of things that just work though which is why i was happy to merge the fortify source code. most of that checking is done at compile time, so the runtime overhead is generally small. and in terms of packages that did break, it was (more often than not) because they were broken already but we never noticed. -mike Hi Debian has start to add some hardened features but take a look at ubuntu https://wiki.ubuntu.com/Security/Features Adding ssp support to main would not be a problem for most package works with it. We use same patch as ubuntu's toolchain to enable ssp, but we enable -fstack-protector-all instead of -fstack-protector. You will, however, have some performance penalty enabling it. Adding PIE to main is much harder than ssp. On x86 it will have a high performance penalty and a lot of trouble with asm code. The only arch I would add PIE on is amd64 where it will have only a minor performance penalty and we already have shared libs compile with PIC. The biggest problem we have with PIE on amd64 is asm code in the apps where upstream is not that interested in making the asm PIC aware. It hards to keep the patches up to date when they are not maintained upstream. There are about 30 packages which have problems with PIE. We either add patch to these or else use filter-flags on them. my 2c /Magnus (Zorry)
