realpath(3) et al

[Devon H. O'Dell]

It, would though, be trivial to implement this with a #define based upon the
kernel configuration, would it not? Protecting against stack smashing is
quite important; I think many hosting environments not using LISP or other
executable-stack-reliant packages would benefit from this. By negating the
ability to execute injected code through a buffer overflow, security is
highly increased. By implementing it as a kernel configuration option, I
don't think we would lose out at all.

Kind regards,

Devon H. O'Dell
Systems and Network Engineer
Simpli, Inc. Web Hosting
http://www.simpli.biz

> -----Oorspronkelijk bericht-----
> Van: owner-freebsd-security at freebsd.org [mailto:owner-freebsd-
> security at freebsd.org] Namens Peter Jeremy
> Verzonden: Tuesday, August 12, 2003 1:15 PM
> Aan: Devon H. O'Dell
> CC: security at freebsd.org
> Onderwerp: Re: realpath(3) et al
> 
> On Tue, Aug 12, 2003 at 11:02:16AM +0200, Devon H. O'Dell wrote:
> >Features such as a protected stack should, IMO, be implemented as soon as
> >possible to keep FreeBSD heads-afloat right now in the security sense....
> >OpenBSD has implemented this already and there are many patches for Linux
> to
> >do the same... why don't we go ahead and shove some of this code into
CVS?
> 
> By "protected" I presume you mean "non-executable".  Whilst making the
> stack non-executable is trivial, making the system still work isn't.
> I believe the FreeBSD signal handling still relies on a signal
> trampoline on the stack.  Some ports also expect an executable stack
> (most commonly lisp implementations).
> 
> Some years ago, I tried implementing a non-executable stack on a
> Solaris box.  Interleaf promptly stopped working so I had to undo the
> change.
> 
> Peter
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-
> unsubscribe at freebsd.org"