[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Feb 2012 23:13:38 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: -Wl,-z,now (was: %optflags for new gcc)
On Sun, Feb 05, 2012 at 13:59 +0400, Solar Designer wrote:
> 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.
Probably you're right, I'll try to do test it with "make buildworld".
I'm sure it is not visible to user in such environment where gcc runs
longer by order of magnitude compared to scripts. We could test the
slowdown of 'configure' stage, probably it would be more representative.
> 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?
It is -z,lazy.
binutils' ld/emultempl/elf32.em:
else if (strcmp (optarg, "now") == 0)
{
link_info.flags |= (bfd_vma) DF_BIND_NOW;
link_info.flags_1 |= (bfd_vma) DF_1_NOW;
}
else if (strcmp (optarg, "lazy") == 0)
{
link_info.flags &= ~(bfd_vma) DF_BIND_NOW;
link_info.flags_1 &= ~(bfd_vma) DF_1_NOW;
}
> 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.)
I cannot find anything similar.
> 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)?
I don't think it is universal - one could reset environment without
running any .*shrc scripts or running PAM routines and all process
subtree will be unprotected.
> Or should we even patch our dynamic linker such that it'd assume
> LD_BIND_NOW for SUID/SGIDs?
That's a good idea.
> 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?
Well, then it would have to actually execute a binary compiled with
-z,lazy and see what's happening with section permissions. And check it
for both non-SUID -z,lazy and SUID -z,lazy binaries. Yes, I think it is
a good way to go.
--
Vasiliy
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
