Buffer overflow?

[Matthew Dillon]

:
:-On [20030801 08:02], Richard Coleman (richardcoleman at 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
:someone.

    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 
    related projects.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>