On Thu, 2004-09-23 at 00:01, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> OK, there's too much arguing and not enough useful discussion going on
> here.  I suggest if you go through with this that you start with the
> following in mind and build from there.
> 
> 1.  Protect daemons and chmod +s programs
The wording on this could be a bit confusing for some. To make it clear
no additional apps are getting a +s bit. This proposal is apps that have
a setuid mode_t -4000 (going for setgid mote_t -2000 as well?) bit have
fstack-protector placed on them as a proactive security measure.


> 
> For our purposes, let's define a daemon as any program which interacts
> with (processes data from) non-root processes, including processes from
> other machines.  This would cover apache and ssh as well as anything
> that happened to provide services to the local box through SysV IPC or
> other mechanisms.
> 
> 2.  Use a FEATURES flag to implement
> 
> The FEATURES flag I've seen most suggested by persons other than me is
> 'autossp'.  This flag should cause a portage command (such as
> apply-autossp) to append -fstack-protector to CFLAGS.  Optionally,
> 'autosspall' should apply -fstack-protector-all.
> 
> It's no secret that -fstack-protector-all breaks some programs that
> - -fstack-protector doesn't (i.e. Firefox, Thunderbird, Mozilla).  In case
> of an 'autosspall' FEATURES flag and broken daemons, the 'apply-autossp
> no-all' command could tell apply-autossp to use -fstack-protector and
> NOT -fstack-protector-all.
> 
> 3.  Is this on by default?
> It's believed by some of us, me included, to be sane to implement
> 'autossp' by default.  Personally, I'm against -fstack-protector-all
> ('autosspall') by default; others may disagree.  I do not have a strong
> understanding of the difference between -fstack-protector and -all; I
> know what they technically do, but not what the extra instrumentation
> code generated with -all will actually gain you.  Others know more than I.
> 
> Remember that if this is on by defaut, any user can add "-autossp" to
> FEATURES in make.conf.  If it's genuinely harmless (I believe it is),
> there's really no point in making the user explicitely enable it.


I'll vote YES on -fstack-protector an NO on the -fstack-protector-all by
default for the conditions you have outlined.

ebuilds such as xfree which have problems right now due to improper
handling of ELF will restrict it's use with RESTRICT="autossp" or just
not make use it.

No profile will need to contain FEATURES=autossp (it's assumed by
default)

The ebuild logic should/will work as follows.

inherit flag-o-matic

src_unpack() {
    unpack ${A}
    ...
   hasq autossp ${RESTRICT} || append-flags -fstack-protector
   ...
}


SpanKY this sound about right?


> 
> - --
> gentoo-dev@g.o mailing list
> 
> 
> 
> - --
> All content of all messages exchanged herein are left in the
> Public Domain, unless otherwise explicitly stated.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFBUkqFhDd4aOud5P8RAgpqAJ9cUJczw09u8Fc2WxQwCn+1AVsy6QCfbhBK
> lBcaH1OZfs+5OcZR6f2V9hE=
> =1K/B
> -----END PGP SIGNATURE-----
> 
> --
> gentoo-dev@g.o mailing list
-- 
Ned Ludd <solar@g.o>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer