kevin_lyons at ofdengineering.com
Wed Jun 30 08:05:05 PDT 2004
Christian Weisgerber wrote:
> Kevin Lyons <kevin_lyons at ofdengineering.com> wrote:
>>Is this the right way to go? We're adding more bloat while openbsd is
>>cleaning itself and reworking kernal memory allocation to make exploits
> Er, what?
Er, read the following (from http://www.openbsd.org/security.html). I
believe they've been doing the random malloc/mmap since 3.4. Almost a
1) "As we audit source code, we often invent new ways of solving
problems. Sometimes these ideas have been used before in some random
application written somewhere, but perhaps not taken to the degree that
* strlcpy() and strlcat()
* Memory protection purify
o .rodata segment
o Guard pages
o Randomized malloc()
o Randomized mmap()
o atexit() and stdio protection
* Privilege seperation
* Privilege revocation
* Chroot jailing
* New uids
* ... and others "
2) If that is not clear enough... from
OpenBSD 3.3 adds page-level memory permissions (on SPARC, Alpha and
PA-RISC CPUs) that mark each memory page as either writable or
executable (but not both at once), to make it harder for an attacker to
write attack code into a memory location and execute it.
Unfortunately, this feature isn't provided on x86 or PowerPC chips yet,
although it's planned for the OpenBSD 3.4 release.
The OpenBSD project has made a decision against
trusted-operating-system-style mandatory access controls that place
kernel-enforced limits on what particular processes or users can do.
"People who use such things build systems which cannot be administered
later," said Theo de Raadt, OpenBSD project leader, in Calgary, Alberta.
"I am holding the fort against such complexity."
OFD Engineering, 950 Threadneedle Suite 250, Houston Texas 77079
Phone: 281-679-9060, ext. 118, E-mail: kevin_lyons at ofdengineering.com
More information about the freebsd-chat