Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 Feb 2012 13:59:32 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: -Wl,-z,now (was: %optflags for new gcc)

On Sat, Feb 04, 2012 at 07:50:54PM +0400, Vasiliy Kulikov wrote:
> 8) -Wl,-z,now
> 
> I agree with Pavel here that we should use secure defaults and disable
> -z,now only for those binaries which do suffer from slow startups like
> php or perl.  Are there other widespread use cases where startup
> slowdown is significant?

I think speed of invocation of various coreutils commands from shell
scripts might be relevant in case of scripts with loops.

As an experiment, we may try to see the effect of having -Wl,-z,now
applied globally on Owl rebuild times (that is, for rebuilds on a system
that was already built in one of these two ways).  These are dominated
by gcc, so should probably be unaffected, but we may try anyway.

In case we enable -Wl,-z,now as gcc default, how do we (or our users)
disable it on individual occasions?  For relro, there's norelro - but is
there a nonow?

Is there an environment variable to negate the effect of -z now?
(I think not, but it may be nice to have one for non-SUID/SGID.)

Should we possibly enable it at build time for SUID/SGID only, but for
the rest set LD_BIND_NOW instead (e.g., set it somewhere at bootup such
that it's normally inherited by everything)?  (After making sure that it
achieves the desired effect, which I am currently unsure of - somehow I
did not spot an mprotect() to read-only in a strace I did.)

Or should we even patch our dynamic linker such that it'd assume
LD_BIND_NOW for SUID/SGIDs?  We might want to do it to better protect
third-party SUID/SGIDs that might be installed on an Owl system even if
we use -z now for our own builds.  The same applies to setting
LD_BIND_NOW for other programs.

Besides actual security (and speed), should we also consider what
checksec.sh will be saying about Owl?  If we change the dynamic linker's
default, checksec.sh currently won't detect that.  A reason for us to do
things like others do or to provide a patch for checksec.sh?

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ