During the last few months Chuck Silvers has refined the support for non-executable mappings on NetBSD. Non-executable mappings make parts of the stack and heap non-executable when they are marked writable. This makes exploiting potential buffer overflows harder.Since there seems to be some confusion about which platforms support non-executable mappings, a separate page is added to the NetBSD website with detailed information about the current state of non-executable mappings.
NetBSD Non-executable Mappings Update
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Paranoia belongs strictly in OpenBSD
“Paranoia belongs strictly in OpenBSD ”
wrong. it belongs to every operating system. fyi linux has exec shield, windows sp is supposed to have NX protection and freebsd and openbsd has stack protection too
Anybody knows when NetBSD 1.6.3 is due for release? I am patiently waiting for it.
I was just joking, since this is normally the stuff we see in the OpenBSD camp – paranoia is good for you, in some cases at least.
Hell I’m playing with SELinux on FC2 right now, just for fun, and FC2 is suppose to have some protection that’s similar called exec-shield.. so I guess my position is that paranoia is good, it’s even better when it can be made transparent to the end user.
According to the release engineering information (the release process has already started) NetBSD 2.0 (not 1.6.3, due to 2.0 being the first release with SMP support and pthread support) is due in “late May”, though of course like nearly any other non-trivial software project that is subject to change.
“Hell I’m playing with SELinux on FC2 right now, just for fun, and FC2 is suppose to have some protection that’s similar called exec-shield”
read the fedora selinux faq and parts of exec shield is already in 2.6.6
OS-level protection is going to become very important as viruses and hacks get more advanced, protections need to get better. I wonder which OS is going to be the first to ban all non-safe* code by default. Probably OpenBSD…
* Defined as either native code compiled by a safe compiler or unsafe code running in a VM.
> I wonder which OS is going to be the first to ban
> all non-safe* code by default. Probably OpenBSD…
>
> * Defined as either native code compiled by a safe
> compiler or unsafe code running in a VM.
Been there, done that: SELinux
You just need an SELinux config file that marks your
trusted compiler as executing in a special domain that
is allowed to create files with a type that can be
executed by any other domain.
Of course, I don’t suggest trusting gcc.
“Of course, I don’t suggest trusting gcc. ”
any reasons for that. a selinux domain would contain it within very specific limits anyway
What would you consider a trust-worthy compiler, and what would you say is the best OSS one?
And would sandboxed languages deserve to be anymore trust-worthy like Python/Perl/Erlang/Ruby ?
I find it refreshing to read news that aren’t about people getting sued over patents, copyrights or other annoyances. At least, with free operating systems, most of the time it’s about progress in software development, not situations which remind us the nuisance caused by SCO, Microsoft and the other profiteers.
Hopefully Linux will add native PaX support in the future.
NetBSD is great, good to see them adding features like this. Probably my second favorite OS over all.
Good software with good hardware. Times to switch to amd64 then
.
“I wonder which OS is going to be the first to ban all non-safe* code by default. Probably OpenBSD…”
NetBSD 2.0 will support verified executable loading. This means a fingerprint for an executable file has to match before execution is allowed. You can try NetBSD 2.0 Beta to see how it works (and help testing NetBSD 2.0 at the same time
.
to have hardware support for non-executable pages?
> I wonder which OS is going to be the first to ban all non-safe* code by default. Probably OpenBSD…
I don’t think so. IMO furthest along is JNode ( http://www.jnode.org ), which is completely written in Java modulo one directory with i386 assembler for bootup, interrupt handling.
“Of course, I don’t suggest trusting gcc.”
Which leads to you suggesting not trusting OpenBSD, NetBSD, FreeBSD and about any (any i can think of) Linux distribution either — they all contain binaries compiled with GCC. Ever saw a kernel compiled with ICC? I haven’t but it possibly exists yes. GCC has a ProPolice patch since 3.3.x which detects broken or possibly broken code. Futhermore, there are programs like Valgrind which help debugging. And no, the 3 major BSD’s don’t use TenDRA (yet).
If everything is set up correctly with ie. systrace, PaX, SELinux (i wouldn’t suggest to trust the NSA!) the only dangerous part remains the kernel itself. Chose wisely.
Which leads to you suggesting not trusting OpenBSD, NetBSD, FreeBSD and about any (any i can think of) Linux distribution either — they all contain binaries compiled with GCC
I believe that Linux, FreeBSD and DragonFly can all be compiled with other compilers. I know I’ve done it on a friends box with Intel’s C compiler, and I’ve had nothing but good luck with tendra. In the modern world, the absolute requirement for GCC when building open source software is a fantasy, a throwback from a previous time.
i wouldn’t suggest to trust the NSA!
Hell, I’m not an American, and I sometimes get quite vocal about how much I dislike their policies and leaders, and I trust the NSA to be something other than a shady, evil American organization!
And I am the paranoid type.