Re: [gentoo-hardened] ssp random bytes solution

[Ned Ludd]

On Mon, 2004-04-19 at 22:29, Robert Connolly wrote:
> On April 19, 2004 09:16 pm, Ned Ludd wrote:
> > On Mon, 2004-04-19 at 17:55, Robert Connolly wrote:
> >>...
> > Could you test the following attachment (guard-test) a few times and
> > post the results?  Mainly I'd like to verify that your __guard is infact
> > working as expected. (It should SEGFAULT or SIGABRT)
>
> ./guard-test
> main    =       0x800009d4;
> __guard =       0x4012aba0;
> __stack_smash_handler   =       0x4002de50;
> __guard =       0x4012aba0;
> __stack_smash_handler   =       0x4002de50;
> guard-test: stack smashing attack in function mainAborted

And how about a second run... __guard is at a different location?

>
> > I took a quick look at the (glibc) code and it appears as if you drooped
> > support completely for /dec/urandom I'm not sure if that's a good idea
> > because if a user decides not to use frandom then she will end up with
> > the default canary only which would weaken the entire model..
>
> That doable. But sysctl random_uuid could also be used as a second fallback. /

kernel.random.uuid can only be read by uid 0
Actually I'm not 100% sure on this because I've had my /proc/sys
restricted for so long thanks to grsecurity..


> dev/{e,f}random third, urandom fourth... I just used sysctl erandom so not to
> make it too complicated for now.

What would be the point of even looking for /dev/{e,f} if the sysctl()
failed?  Either we are using frandom or not. Right?

I would think the logic would work something like this untested
attachment.

> > Also can this be enabled in the kernel as non LKM?
> > As handy as modules are they are a security risk and should be avoided
> > at all costs.
>
> As in built in? yes. The sysctl support will not work as a module.
>
>
> --
> gentoo-hardened@g.o mailing list
-- 
Ned Ludd <solar@g.o>
Gentoo Linux Developer