Mailing List Archive

Frank Peters posted on Mon, 16 Jun 2014 20:18:59 -0400 as excerpted:

> GCC-4.8.3 is now in the portage tree and it enables SSP, or Stack
> Smashing Protection, by default.
>
> I don't want SSP. It can be disabled using the -fno-stack-protector
> flag.
>
> Checking the portage use.local.desc file, it seems a better way to
> disable SSP is to specify the "nossp" USE flag for gcc. With this USE
> flag set, gcc will be built without SSP.
>
> However the "nossp" USE flag has some sort of warning attached to it in
> the use.local.desc file:
>
> sys-devel/gcc:nossp - Disable SSP support (NOT FOR GENERAL USE)
>
> What does this mean? Is it safe to use the "nossp" USE flag to build
> gcc?

Based on the discussions on the dev list, I believe the nossp USE flag
was originally only for specific-case usage in the hardened profiles, and
now will likely be expanded to the archs (like hppa I believe) where ssp
doesn't work. As such, I'd consider it quite likely that the flag will
eventually be masked on general profiles, since the idea is to make gentoo
a bit safer by enabling it in general, and disabling it only on archs
where it is known not to work (hppa I believe, among others).

While it is of course possible to unmask such a flag and then use it, I'd
consider strongly before you do as that puts you FAR out of tested gentoo
mainstream.

That said, in theory at least it should "just work", since this is a
change to the /gentoo/ gcc spec-file defaults, not upstream, and turning
it off is simply turning off a newly default feature that has until now
been off unless you specifically turned it on.

But I'd still strongly recommend adding the -fno-stack-protector to your
CFLAGS, as that will continue to be supported by gentoo, while messing
with gcc's nossp flag is not recommended and may result in bugs being
closed INVALID or NEEDINFO (duplicate with the flag toggled before
reopening), etc, as a result.

/That/ said, there's actually three levels of ssp now, with this one the
lowest level, dropping performance very little while focusing protection
on the functions that are easiest to abuse AND to protect. Actually, as
the news item states, the middle (strong but not all) option is the
planned default for gcc 4.9. That being the case, I'd at /least/
recommend this lower level of protection on at least the most critical
functions where the performance cost is quite low in comparison to the
benefit. If you want to disable the strong-but-not-all default when it
comes in 4.9, OK, but I'd suggest at least keeping this minimal threshold
of protection, particularly since it /will/ be the default now and thus
there should be if anything fewer problems with it than not.

But it's you're machine, and we'd not be gentooers if we didn't want to
be king over the configuration of our own machines, so go to it if you
are sure. =:^) Just do your research (perhaps you already have) and
know exactly why you're doing it.

--
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

On Tue, 17 Jun 2014 07:11:26 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> If you want to disable the strong-but-not-all default when it
> comes in 4.9, OK, but I'd suggest at least keeping this minimal threshold
> of protection, particularly since it /will/ be the default now and thus
> there should be if anything fewer problems with it than not.
>

The problem with all Linux distributions, and not just Gentoo, is that
they are directed toward a multi-user, networked environment. As a
consequence, they exhibit security and other features that generally
make no sense whatsoever for a single-user desktop machine that optionally
connects externally only with an ISP through a router/modem.

I continually have configuration problems because of the need to
work around the useless (vis-a-vis the single-user desktop) and
myriad requirements of the multi-user, networked scenario.

In the single-user, desktop environment, the probability of a buffer
overflow "attack" is virtually nil, especially if one is highly selective
about "surfing" the Internet and employing Internet software (which
I am).

There needs to be a Linux distribution or sub-distribution that caters
to the needs of the single, desktop user, ensconced as he is within
his private garret and far removed from the troubles of a massive
network. My system is configured in a way that is quite contrary
to recommended Linux practice (for example I run only and always as the
root superuser and have no need for file permissions) but yet it makes
perfect sense for my situation.

Are single desktop users that much of a minority? I would hope not.

Frank Peters

A ) building gcc without spp does not disable spp for other packages.
B) spp is a good thing even for single user desktops.
C) i hate long answers without useful content.
D ) i hate the quoting of my phone.
Am 17.06.2014 15:05 schrieb "Frank Peters" <frank.peters@comcast.net>:

> On Tue, 17 Jun 2014 07:11:26 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
> > If you want to disable the strong-but-not-all default when it
> > comes in 4.9, OK, but I'd suggest at least keeping this minimal threshold
> > of protection, particularly since it /will/ be the default now and thus
> > there should be if anything fewer problems with it than not.
> >
>
> The problem with all Linux distributions, and not just Gentoo, is that
> they are directed toward a multi-user, networked environment. As a
> consequence, they exhibit security and other features that generally
> make no sense whatsoever for a single-user desktop machine that optionally
> connects externally only with an ISP through a router/modem.
>
> I continually have configuration problems because of the need to
> work around the useless (vis-a-vis the single-user desktop) and
> myriad requirements of the multi-user, networked scenario.
>
> In the single-user, desktop environment, the probability of a buffer
> overflow "attack" is virtually nil, especially if one is highly selective
> about "surfing" the Internet and employing Internet software (which
> I am).
>
> There needs to be a Linux distribution or sub-distribution that caters
> to the needs of the single, desktop user, ensconced as he is within
> his private garret and far removed from the troubles of a massive
> network. My system is configured in a way that is quite contrary
> to recommended Linux practice (for example I run only and always as the
> root superuser and have no need for file permissions) but yet it makes
> perfect sense for my situation.
>
> Are single desktop users that much of a minority? I would hope not.
>
> Frank Peters
>
>
>

Am 17.06.2014 16:11, schrieb Volker Armin Hemmann:
>
> A ) building gcc without spp does not disable spp for other packages.
>

and I am wrong on that. nossp seems to disable ssp on general. Still not
a good idea.

On Tue, Jun 17, 2014 at 9:04 AM, Frank Peters <frank.peters@comcast.net> wrote:
>
> The problem with all Linux distributions, and not just Gentoo, is that
> they are directed toward a multi-user, networked environment. As a
> consequence, they exhibit security and other features that generally
> make no sense whatsoever for a single-user desktop machine that optionally
> connects externally only with an ISP through a router/modem.
>...
> My system is configured in a way that is quite contrary
> to recommended Linux practice (for example I run only and always as the
> root superuser and have no need for file permissions) but yet it makes
> perfect sense for my situation.
>

Keep in mind that there are many elements to data security. Not
beeing pwned by script kiddies is certainly one of them, and that
doesn't really apply so much to the single-user desktop. However, if
you take a broader definition of data security then things become more
nuanced.

Let's define data security as "the prevention of unintended
destruction or dissemination of data stored on a system, or an
unintended loss of system functionality."

When you use a broader definition then security really ought to be
important to the single-user desktop. Features that should be
considered important include:
* Disaster recovery / backups / etc.
* Prevention of unintentional system changes (ie don't be root)
* Robustness in the face of or rapid recovery from common failure
modes (ie RAID, rapid restoration, etc).
* Protection from whatever is lurking in that banner ad your browser
just downloaded (ie SSP/SELinux/etc).

So, I wouldn't be too quick to dismiss security. My only
personally-owned laptop is a Chromebook and its features include being
trivial to restore to factory condition, having all data backed up
online continuously, having full-disk encryption, and having automatic
updates to keep all of that stuff working. That certainly isn't the
only model for a desktop machine, but from a data-security standpoint
it is about as good as it gets, and it is the result of a design that
keeps security in mind.

Rich

On Tue, 17 Jun 2014 16:11:38 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> A ) building gcc without spp does not disable spp for other packages.
>

Not that I do not trust you, but I need to check this out.

Is there some other way to make SPP the non-default for all
packages?

Frank Peters

Rich Freeman <rich0@gentoo.org> skribis:
> Keep in mind that there are many elements to data security.

Put simply, in the context of stack smashing, it consists of
protection against any form of program running astray, whether it does
so by design or not.

Someone running everything as superuser is in what you might call an
‘MSDOS’ situation -- presumably both knows that and finds the risks
acceptable. Turning off stack smashing protection makes sense to me,
in that case.

On Tue, 17 Jun 2014 19:04:00 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

>
> nossp seems to disable ssp on general. Still not
> a good idea.
>

I appreciate your concern but, all too often it seems, the notion
of "not a good idea" becomes "not a good idea therefore it should
be irrevocably disabled for everyone whether they want it or not."

An option should never become a law.

Frank Peters

Am 17.06.2014 20:47, schrieb Frank Peters:
> On Tue, 17 Jun 2014 19:04:00 +0200
> Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
>
>> nossp seems to disable ssp on general. Still not
>> a good idea.
>>
> I appreciate your concern but, all too often it seems, the notion
> of "not a good idea" becomes "not a good idea therefore it should
> be irrevocably disabled for everyone whether they want it or not."
>
> An option should never become a law.
>
> Frank Peters
>
>
>

options increase the workload on devs&testers a lot.

So removing options makes sense in a way. Especially if it is about a
feature that should never be turned off.

Frank Peters <frank.peters@comcast.net> skribis:
> I appreciate your concern but, all too often it seems, the notion
> of "not a good idea" becomes "not a good idea therefore it should
> be irrevocably disabled for everyone whether they want it or not."

Yeah, that seems to be common.

There is a tug-of-war between the idea of Gentoo as (a) an OS like the
usual suspects except you can easily compile it yourself and (b) a
framework for rolling your own OS. I lean in preference towards (b).

(The xLFSes are suffering from the same tug-of-war.)

On 06/17/2014 02:04 PM, Frank Peters wrote:
> In the single-user, desktop environment, the probability of a buffer
> overflow "attack" is virtually nil, especially if one is highly
> selective about "surfing" the Internet and employing Internet software
> (which I am). There needs to be a Linux distribution or
> sub-distribution that caters to the needs of the single, desktop user,
> ensconced as he is within his private garret and far removed from the
> troubles of a massive network.

howdy, just out of curiosity what benefits do you gain from disabling ssp ?
is there a speed concern or resource issue ?

Am 17.06.2014 21:57, schrieb Barry Schwartz:
> Frank Peters <frank.peters@comcast.net> skribis:
>> I appreciate your concern but, all too often it seems, the notion
>> of "not a good idea" becomes "not a good idea therefore it should
>> be irrevocably disabled for everyone whether they want it or not."
> Yeah, that seems to be common.
>
> There is a tug-of-war between the idea of Gentoo as (a) an OS like the
> usual suspects except you can easily compile it yourself and (b) a
> framework for rolling your own OS. I lean in preference towards (b).
>
> (The xLFSes are suffering from the same tug-of-war.)
>
>

so make yourself an overlay, put an ebuild with apropriate patches there
and be happy.

Volker Armin Hemmann <volkerarmin@googlemail.com> skribis:
> Am 17.06.2014 21:57, schrieb Barry Schwartz:
> > Frank Peters <frank.peters@comcast.net> skribis:
> >> I appreciate your concern but, all too often it seems, the notion
> >> of "not a good idea" becomes "not a good idea therefore it should
> >> be irrevocably disabled for everyone whether they want it or not."
> > Yeah, that seems to be common.
> >
> > There is a tug-of-war between the idea of Gentoo as (a) an OS like the
> > usual suspects except you can easily compile it yourself and (b) a
> > framework for rolling your own OS. I lean in preference towards (b).
> >
> > (The xLFSes are suffering from the same tug-of-war.)
>
> so make yourself an overlay, put an ebuild with apropriate patches there
> and be happy.

I have _more than one_ overlay, hosted on Bitbucket.

Please try to be nice about this. Is it not even acceptable to discuss
that there is such a tug-of-war? Should discussions about the
balances of pros and cons in Gentoo take place in ‘discussion
overlays’?

On Tue, 17 Jun 2014 22:29:40 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

>
> so make yourself an overlay, put an ebuild with apropriate patches there
> and be happy.
>

Now that is excellent advice.

I've got to get working on this for myself ASAP.

Frank Peters

On Tue, 17 Jun 2014 21:28:14 +0100
thegeezer <thegeezer@thegeezer.net> wrote:

>
> howdy, just out of curiosity what benefits do you gain from disabling ssp ?
> is there a speed concern or resource issue ?
>

Every routine that is not explicitly declared in-line will necessitate
setting up a stack frame which is costly enough already.

With SSP every subroutine call will require an additional reading from
/dev/urandom to set up the "canary" value. This my also deplete the
kernel entropy pool.

If you want it take it but please allow me to opt out.

Frank Peters

Frank Peters <frank.peters@comcast.net> skribis:
> On Tue, 17 Jun 2014 22:29:40 +0200
> Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
>
> >
> > so make yourself an overlay, put an ebuild with apropriate patches there
> > and be happy.
> >
>
> Now that is excellent advice.
>
> I've got to get working on this for myself ASAP.

I’d recommend it. Have been doing it for years, and it is well
supported these days.

I happen to agree that in this case it is the appropriate approach.

Am 17.06.2014 22:51, schrieb Barry Schwartz:
> Volker Armin Hemmann <volkerarmin@googlemail.com> skribis:
>> Am 17.06.2014 21:57, schrieb Barry Schwartz:
>>> Frank Peters <frank.peters@comcast.net> skribis:
>>>> I appreciate your concern but, all too often it seems, the notion
>>>> of "not a good idea" becomes "not a good idea therefore it should
>>>> be irrevocably disabled for everyone whether they want it or not."
>>> Yeah, that seems to be common.
>>>
>>> There is a tug-of-war between the idea of Gentoo as (a) an OS like the
>>> usual suspects except you can easily compile it yourself and (b) a
>>> framework for rolling your own OS. I lean in preference towards (b).
>>>
>>> (The xLFSes are suffering from the same tug-of-war.)
>> so make yourself an overlay, put an ebuild with apropriate patches there
>> and be happy.
> I have _more than one_ overlay, hosted on Bitbucket.

I don't. I do not see the need.

>
> Please try to be nice about this. Is it not even acceptable to discuss
> that there is such a tug-of-war? Should discussions about the
> balances of pros and cons in Gentoo take place in ‘discussion
> overlays’?
>
>
>

Was this thread started to 'discuss' something? No? Then why do you feel
the need to start one?

Especially about something like ssp that hardly anybody should want to
turn off?

And I am nice. At the moment.

I wrote:
> Frank Peters <frank.peters@comcast.net> skribis:
> > On Tue, 17 Jun 2014 22:29:40 +0200
> > Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> >
> > >
> > > so make yourself an overlay, put an ebuild with apropriate patches there
> > > and be happy.
> > >
> >
> > Now that is excellent advice.
> >
> > I've got to get working on this for myself ASAP.
>
> I’d recommend it. Have been doing it for years, and it is well
> supported these days.
>
> I happen to agree that in this case it is the appropriate approach.

BTW it probably helps to be aware that (unless things have changed
since I was using an overlay for it) new gcc ebuilds come through the
‘hardened’ overlay. IMO they are probably the best qualified for the
job, generally speaking.

On Tue, 17 Jun 2014 16:38:52 -0500
Barry Schwartz <chemoelectric@chemoelectric.org> wrote:

> ... programs
> having been written in the wrong languages to start with. (I mean,
> where buffer overruns come from isn’t hard to figure out. They come
> from using C and C++ to write the code.)
>

Wrong language? I won't even touch this. If I did, it would likely
escalate to a savage exchange on the philosophy of programming.

Since I "cut my teeth" on assembly language, I have an undying fondness
for C. Yet the universal trend is to leave the actual machine behind
and embrace the lofty abstractions of object oriented languages.
Indeed, a good deal of computing power today is used to support the massive
layers of abstraction that obliterate a sense of hardware and make life
easy for the programmer.

But I've said enough already.

Frank Peters

On Tue, Jun 17, 2014 at 2:47 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Tue, 17 Jun 2014 19:04:00 +0200
> Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
>
>>
>> nossp seems to disable ssp on general. Still not
>> a good idea.
>>
>
> I appreciate your concern but, all too often it seems, the notion
> of "not a good idea" becomes "not a good idea therefore it should
> be irrevocably disabled for everyone whether they want it or not."
>

Usually use flags that are discouraged are intended mainly to solve
limitations in how we express dependencies/etc. It isn't that we
don't want users to use them, but more that in the future we might
change how they work and they could go away, causing trouble for those
who depend on them. Think of them as unintentionally-exposed private
interfaces.

If there is something you want to do and there isn't a supported way
to do it, feel free to discuss/ suggest/ beg/ etc.

But, if you're told that doing something in a particular way isn't a
good idea, be sure you understand why before you do it anyway. :)

Rich

Frank Peters <frank.peters@comcast.net> skribis:
> Subject: Re: [gentoo-amd64] Re: Disable SPP On GCC-4.8.3
> From: Frank Peters <frank.peters@comcast.net>
> Reply-to: gentoo-amd64@lists.gentoo.org
> Date: Tue, 17 Jun 2014 18:21:05 -0400
> To: gentoo-amd64@lists.gentoo.org
>
> On Tue, 17 Jun 2014 16:38:52 -0500
> Barry Schwartz <chemoelectric@chemoelectric.org> wrote:
>
> > ... programs
> > having been written in the wrong languages to start with. (I mean,
> > where buffer overruns come from isn’t hard to figure out. They come
> > from using C and C++ to write the code.)
> >
>
> Wrong language? I won't even touch this. If I did, it would likely
> escalate to a savage exchange on the philosophy of programming.
>
> Since I "cut my teeth" on assembly language, I have an undying fondness
> for C. Yet the universal trend is to leave the actual machine behind
> and embrace the lofty abstractions of object oriented languages.
> Indeed, a good deal of computing power today is used to support the massive
> layers of abstraction that obliterate a sense of hardware and make life
> easy for the programmer.
>
> But I've said enough already.
>
> Frank Peters
>
>

I cut my teeth on a TRS-80 with TBUG. Not even an assembler.

Rich Freeman <rich0@gentoo.org> skribis:
> Usually use flags that are discouraged are intended mainly to solve
> limitations in how we express dependencies/etc. It isn't that we
> don't want users to use them, but more that in the future we might
> change how they work and they could go away, causing trouble for those
> who depend on them. Think of them as unintentionally-exposed private
> interfaces.

My view on this current problem is that, given -fno-stack-protector in
the make.conf works nearly everywhere, there isn’t a problem as far as
building the OS is concerned. As for a ‘user compiler’, this seems not
to be a serious change, either.

(An example of actually making life harder for a user are the
default-settings changes in Debian’s GNU linker. They make it harder
than with stock GNU to construct dynamic plugins.)

On Tue, Jun 17, 2014 at 6:01 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Rich Freeman <rich0@gentoo.org> skribis:
>> Usually use flags that are discouraged are intended mainly to solve
>> limitations in how we express dependencies/etc. It isn't that we
>> don't want users to use them, but more that in the future we might
>> change how they work and they could go away, causing trouble for those
>> who depend on them. Think of them as unintentionally-exposed private
>> interfaces.
>
> My view on this current problem is that, given -fno-stack-protector in
> the make.conf works nearly everywhere, there isn’t a problem as far as
> building the OS is concerned. As for a ‘user compiler’, this seems not
> to be a serious change, either.
>
> (An example of actually making life harder for a user are the
> default-settings changes in Debian’s GNU linker. They make it harder
> than with stock GNU to construct dynamic plugins.)
>

As this topic is on-going, let my ask about -fno-stack-protector. I
haven't messed with my build flags in literally years, and certainly
not since I built this machine in 2010 where I only use CFLAGS="-O2
-march=native -pipe" . WRT to -fno-stack-protector does enabling a
flag like that in make.conf then trigger a requirement to rebuild
everything (emerge -e @world) or can one turn it on and just update
the machine package-by-package over time?

- Mark

Mark Knecht <markknecht@gmail.com> skribis:
> As this topic is on-going, let my ask about -fno-stack-protector. I
> haven't messed with my build flags in literally years, and certainly
> not since I built this machine in 2010 where I only use CFLAGS="-O2
> -march=native -pipe" . WRT to -fno-stack-protector does enabling a
> flag like that in make.conf then trigger a requirement to rebuild
> everything (emerge -e @world) or can one turn it on and just update
> the machine package-by-package over time?

If you _do not_ enable -fno-stack-protector you will get packages
updated over time, once you start using 4.8.3+ as your system
compiler. Enabling -fno-stack-protector is the way to keep things the
same.