DragonFly kernel List (threaded) for 2003-08
Re: Buffer overflow?
:-On [20030801 08:02], Richard Coleman (richardcoleman@xxxxxxxxxxxxxx) wrote:
:>Have you given any thought to pulling in the changes that OpenBSD made
:>to harden against buffer overflows (i.e. canary checking)? They've
:>added some pretty serious mechanisms to make it harder to exploit buffer
:>overflows (and made it turned on by default).
:IIRC Hiten is busy working on getting the OpenBSD non-exec stack code
:working on DragonFly.
:Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
:PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
:http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
:How many cares one loses when one decides not to be something but to be
Well, I am neutral on the topic. I generally consider these
sorts of security fixes as masking the problem rather then
fixing it. What I would like to see (and another reason for
doing the VFS layer and syscall emulation) is a way to limit
a program's ability to manipulate its environment to just
the files that we say it can access/modify. Also, the ability
to wrap a program with another program which takes control of
its syscalls (another reason for doing syscall messaging).
As an extreme example take a program like 'ls'. There is
no reason under the sun for the system to allow a program
like 'ls' to exec(), yet nearly all UNIX systems do allow
this. You get the drift of where I'm going...
The key is to make this all doable in userland. Restricting
these sorts of features to the kernel greatly reduces the
number of people who can potentially develop code up