Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_install_serviced().
Dnia 2013-09-08, o godz. 13:12:26
Michał Górny mgo...@gentoo.org napisał(a):
This function can be used to install service configuration templates.
Usage:
systemd_install_serviced ${FILESDIR}/foo.service.conf
or:
systemd_install_serviced ${FILESDIR}/barbaz foo.service
with the latter specifying related service name explicitly, former
expecting it to match ${basename%.conf}. The files are installed as:
/etc/systemd/system/foo.service.d/00gentoo.conf
They should be commented out templates that users can use to customize
the service easily.
Improved wrt received feedback and committed.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Improve the security of the default profile
On 09/12/2013 11:03 AM, Richard Yao wrote: On 09/10/2013 09:17 PM, Rich Freeman wrote: On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao r...@gentoo.org wrote: 1. The kernel expects -fno-stack-protector to be the default. What will the effect be on kernel configuration once -fstack-protector is the default? Nothing, since the kernel build system doesn't source make.conf. If somebody creates an ebuild that actually installs a kernel then it might be an issue, though it could be filtered if it is a problem. My understanding is that this change would be made to GCC's spec files, which affects everything that uses GCC. 2. We should make sure that -fno-stack-protector is a supported CFLAG. This will make it easier to handle complaints from the vocal minority of our user base that want every last percentage point of performance. No reason that it would be any less supported than -fstack-protector already is. Just making certain. 3. I would like to point out that we are talking about deviating from upstream behavior and everyone is okay with it. Anyone who thinks we should stick to upstream when it is not good for us should speak now or risk being asked where were you when... whenever they try to use upstream as an excuse to hold back progress. ;) I don't really see this as an issue - in general maintainers are expected to accommodate reasonable CFLAGS. This doesn't mean that arbitrary CFLAGS are supported so much as bugs should be taken seriously if they're really bugs. If -fstack-protector causes serious problems and this is inherent to the nature of the package/etc then just filter it. If it causes problems because upstream isn't doing things right, then this is no different than how things were 10 years ago when we were stomping out amd64 issues left and right (not working on amd64 wasn't a reason to mask a package for x86, but we didn't accept upstream doesn't care about amd64 as an excuse). Staying close to upstream is a good philosophy in general. I don't think that means that we can't have reasonable CFLAGS. Otherwise we wouldn't set CFLAGS at all and would just use whatever defaults the upstream build system applies. We're a distro - doing integration work is a value-add, not a sin. If we aren't doing integration, then users might as well just do Linux-from-scratch. Rich Past events have led me to think that we are sometimes too dependent on upstream for guidance. I have certainly deviated from upstream whenever it made sense and the results have been fairly positive. I am not saying that acting for the best interests of Gentoo is mutually exclusive with collaboration with upstream, but I am saying that the two sometimes conflict. This being one of them. I am taking this opportunity to point out that what is best for Gentoo should come first and that it is okay to make decisions on our own. I just checked the kernel's makefiles. It does pass -fno-stack-protector when the option is disabled. Therefore a GCC spec file change will not have cause GCC to generate kernels that differ from their .config files. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Improve the security of the default profile
On 09/07/2013 05:11 PM, Ryan Hill wrote:
On Sat, 7 Sep 2013 18:10:42 + (UTC)
Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote:
Ryan Hill dirtye...@gentoo.org wrote:
* -fstack-protector{-all}
No thank you. -fstack-protector has very limited coverage
I'd say it covers most cases where bugs can be made,
practically without a severe impact on execution time or code size.
The numbers I've seen show a maximum of 5% coverage for code that has a large
number of functions containing char arrays on the stack. Most code doesn't fall
into that category. Coverage of perl was 0.5%, xorg 5%, kernel 3%. Those are
really old numbers though. The most recent I've seen is Chromium's coverage is
2%. There is an upper bound of 8% performance overhead using -fstack-protector
according to the design spec. If you guys are okay with that then we can try
enabling it for 4.8.1.
* -Wl,-z,relro
Enabled by default since binutils 2.18
This gives its real impact on secutiry only when combined with
* -Wl,-z,now
The latter is not enabled by default AFAIK.
That's a bit misleading. Immediate binding does allow the GOT to be made
readonly but relro does a lot more than that. In any case this is a firm no.
The increase in loading times for apps that link lots of libraries is
significant (if it wasn't, we wouldn't need lazy loading :p). If you want full
relro, enable it yourself or use hardened.
I would like to suggest also another flag
* -Wl,-z,noexecstack
This should be the default, but e.g. some broken gcc versions
forgot this default when using -flto.
I am using this flag since I realized this -flto bug and never
had any problems with it.
Well, portage will already tell you if your package installed any binaries with
executable stacks and I don't see many of those warnings that aren't binary
packages so I think we're good.
* -Wl,--hash-style={both,gnu}
I don't know what this has to do with security.
I'm just responding to the list on the Ubuntu page.
However, isn't it time to use gnu now for all users? Except for
very strange binary-only code it should not cause any problems.
The majority of users would not realize a difference but profit
from smaller binaries.
Sure, but the sysv hash is teeny and backward compatibility is always nice if
it's next to free.
Here are some more resources if anyone is interested:
https://wiki.debian.org/Hardening
https://bugs.archlinux.org/task/18864
https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart
http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html
The hardened team has talked about this in IRC and our general feeling
is that adding *just* ssp to vanilla gcc specs is okay. While there are
some performance hits, it is generally safe and should cause little
problems to our users. The other hardened features, however, have more
of an impact and probably don't belong in vanilla as already discussed.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
Re: [gentoo-dev] Re: Improve the security of the default profile
On 09/10/2013 09:17 PM, Rich Freeman wrote: On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao r...@gentoo.org wrote: 1. The kernel expects -fno-stack-protector to be the default. What will the effect be on kernel configuration once -fstack-protector is the default? Nothing, since the kernel build system doesn't source make.conf. If somebody creates an ebuild that actually installs a kernel then it might be an issue, though it could be filtered if it is a problem. My understanding is that this change would be made to GCC's spec files, which affects everything that uses GCC. 2. We should make sure that -fno-stack-protector is a supported CFLAG. This will make it easier to handle complaints from the vocal minority of our user base that want every last percentage point of performance. No reason that it would be any less supported than -fstack-protector already is. Just making certain. 3. I would like to point out that we are talking about deviating from upstream behavior and everyone is okay with it. Anyone who thinks we should stick to upstream when it is not good for us should speak now or risk being asked where were you when... whenever they try to use upstream as an excuse to hold back progress. ;) I don't really see this as an issue - in general maintainers are expected to accommodate reasonable CFLAGS. This doesn't mean that arbitrary CFLAGS are supported so much as bugs should be taken seriously if they're really bugs. If -fstack-protector causes serious problems and this is inherent to the nature of the package/etc then just filter it. If it causes problems because upstream isn't doing things right, then this is no different than how things were 10 years ago when we were stomping out amd64 issues left and right (not working on amd64 wasn't a reason to mask a package for x86, but we didn't accept upstream doesn't care about amd64 as an excuse). Staying close to upstream is a good philosophy in general. I don't think that means that we can't have reasonable CFLAGS. Otherwise we wouldn't set CFLAGS at all and would just use whatever defaults the upstream build system applies. We're a distro - doing integration work is a value-add, not a sin. If we aren't doing integration, then users might as well just do Linux-from-scratch. Rich Past events have led me to think that we are sometimes too dependent on upstream for guidance. I have certainly deviated from upstream whenever it made sense and the results have been fairly positive. I am not saying that acting for the best interests of Gentoo is mutually exclusive with collaboration with upstream, but I am saying that the two sometimes conflict. This being one of them. I am taking this opportunity to point out that what is best for Gentoo should come first and that it is okay to make decisions on our own. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Improve the security of the default profile
On 09/11/2013 02:07 AM, Ryan Hill wrote: On Tue, 10 Sep 2013 18:41:34 -0400 Richard Yao r...@gentoo.org wrote: A few thoughts: 1. The kernel expects -fno-stack-protector to be the default. What will the effect be on kernel configuration once -fstack-protector is the default? The kernel has supported building with -fstack-protector since 2.6.19, (at least on x86/x86-64). It's controlled by CONFIG_CC_STACKPROTECTOR and if it's disabled then -fno-stack-protector is explicitly added to the command line. That is good news. I admit that I was being lazy in not looking this up myself, but things probably are more efficient when the people already looking into this are the ones who check these loose ends. 2. We should make sure that -fno-stack-protector is a supported CFLAG. This will make it easier to handle complaints from the vocal minority of our user base that want every last percentage point of performance. If by supported you mean that they won't be removed by things like strip-flags, then yes, -fstack-protector -fstack-protector-all -fno-stack-protector and -fno-stack-protector-all are all on the whitelist. That is good. 3. I would like to point out that we are talking about deviating from upstream behavior and everyone is okay with it. Anyone who thinks we should stick to upstream when it is not good for us should speak now or risk being asked where were you when... whenever they try to use upstream as an excuse to hold back progress. ;) In this case it seems every other distro is already doing this, so we're in good company. Agreed. I just wanted to say something as insurance for the future. ;) Anyway, I will be happy to see it integrated into the tree once all of the hacks around it have been corrected. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: virtual/python-json
# Michał Górny mgo...@gentoo.org (12 Sep 2013) # All currently supported Python implementations have built-in json # module already. This renders the virtual no longer needed. Please # remove your dependencies on it and enjoy json out-of-the-box. # Removal in 30 days. virtual/python-json -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Last rites: virtual/pyparsing
# Michał Górny mgo...@gentoo.org (13 Sep 2013) # Upstream decided to merge the Python 23 variants of pyparsing back # into a single package. We no longer support the split variants, # and therefore the virtual is unnecessary. Please simply depend # on dev-python/pyparsing instead. Removal in 30 days. # Including a mask on removed py23 variants to enforce upgrade. dev-python/pyparsing:py2 dev-python/pyparsing:py3 virtual/pyparsing -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: Improve the security of the default profile
On Thu, 12 Sep 2013 11:23:04 -0400 Anthony G. Basile bluen...@gentoo.org wrote: The hardened team has talked about this in IRC and our general feeling is that adding *just* ssp to vanilla gcc specs is okay. While there are some performance hits, it is generally safe and should cause little problems to our users. The other hardened features, however, have more of an impact and probably don't belong in vanilla as already discussed. https://bugs.gentoo.org/484714 -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
