concurrent sysctl implementation

[Jeremie Le Hen]

On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote:
> * Jeremie Le Hen <jeremie at le-hen.org> wrote:
> > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote:
> > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote:
> > > > Hi Ed,
> > > > 
> > > > Sorry for the late reply.
> > > > 
> > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote:
> > > > > We probably could. I think I discussed this with Robert Watson some time
> > > > > ago and we could use things like ELF hints. But still, that doesn't
> > > > > prevent us from reaching this limitation later on.
> > > > 
> > > > Can you elaborate a little?  Are you talking about elf-hints.h?
> > > > I don't see where we can get randomness from it.
> > > 
> > > The thing is called ELF auxillary information vector. It is used to
> > > supply some useful information for interpreter from the kernel,
> > > see include/machine/elf.h for AT_* entries.
> > 
> > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM,
> > generated at link time, that will be used to fill the canary at exec(2)
> > time?
> 
> Very short answer: yes!

Ok thanks.  But this would make stack protection useless for local
attacks on suid binaries that are world-readable since the attacker
could read the ELF aux vector and compute the canary.  

Upon each invocation, the canary would stay the same which makes
the repeat-until-success attack feasible for daemons that are
automatically respawned.

This saves one syscall per exec(2) but reduce security for the two cases
described above.  In the performance test I've run with and without
-fstack-protector to build world, I saw only around 1 percent penalty.
I must admit this was on a UP system which wasn't loaded though.

I know that the sysctl system may be redesigned in the future to allow
more concurrency.  Is it something that could prevent from changing the
way the canary is initialized?

Regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >