NetBSD 2.0.2 Released

jschauma writes "James Chacon of the NetBSD Release Engineering team has announced that update 2.0.2 of the NetBSD operating system is now available. NetBSD 2.0.2 is the second security/critical update of the NetBSD 2.0 release branch. This represents a selected subset of fixes deemed critical in nature for stability or security reasons. More details are available in the NetBSD 2.0.2 Release Announcement."

I wonder...

[0x461FAB0BD7D2]

if NetBSD 2 SP2 breaks compatibility with Halo.

Re:I wonder...

[Anonymous Coward]

I don't know what Halo is, but NetBSD security upgrades (2.0.x), and even minor upgrades (2.x), normally are 100% backward compatible.

Backward compatibility across major versions (for 1.5, 1.6. ...) can be enabled in the kernel, using e.g. the COMPAT_16 option.

Re:I wonder...

[Anonymous Coward]

Whoosh! Whoosh! Whoosh! He made a funny. WinXP SP2 breaks Halo (the game).

Re:I wonder...

[quamaretto]

Speaking of which, I guess they haven't made an ending for BSD, either...

So, speaking of security,

[hey!]

whatever happened to kernel privilege elevation, which was supposed to allow daemons in BSD to run as unprivileged accounts, but still do things like bind to certain low number IP ports? Supposedly, by making the ability to do certain privileged things fine grained, it reduced the impact of things like buffer overflows.

Is this just part of the BSD landscape now? Did the idea pan out, and is BSD now relatively immune to a large class of security vulnerabilities?

OT, I know, but I remember thinking that if this worked as well as it sounded, it was a good reason to move my Linux servers over to BSD.

Re:So, speaking of security,

[Anonymous Coward]

You may be thinking of systrace [onlamp.com].

Re:So, speaking of security,

[hey!]

Yes, that's it.

So, what's the consensus been about the experience with this. Has it proven to be a huge improvement in security?

Re:So, speaking of security,

[Homology]

So, what's the consensus been about the experience with this. Has it proven to be a huge improvement in security?

Writing systrace policies are alot of work, and requires much testing in order not to break the application. In addition you need knowledge of the system calls involved (pass/deny).

As an example "mv a /b" involves different system calls depending on a is on same filesystem as /b.

Re:So, speaking of security,

[hey!]

So, we're in the same old situation: you can secure your system, but its so much trouble most people won't?

Re:So, speaking of security,

[Anonymous Coward]

Most people wont do the whole system, but individual daemons are not too much work.

I do this with my servers which run a modified postgresql, though I use OpenBSD.

Re:So, speaking of security,

[setagllib]

Well, it all depends how much security you WANT, short of not having a system at all. You can systrace everything and have a crack team of trusted, indoctrinated people constantly watching all traffic and analysing it for signs of attempted intrusion or investigation. Or you can trust the software quality and 'general practice' recommendations even outlined in the BSD handbooks.

It's definitely a fun job though (one I wouldn't mind having), as long as the software is good. The BSDs are good in this regard, and so is Linux with the right patches and tools. But then sometimes a bug will come up nobody expected and it's all for naught :(

Re:So, speaking of security,

[Anonymous Coward]

On all BSD's you can set the lowest "unprivileged bindable" port by means of a sysctl.

Re:So, speaking of security,

[Anonymous Coward]

or, you can redirect the port to a higher number by using NAT.

Re:So, speaking of security,

[hey!]

Well, sure, but that doesn't to squat for security -- it just makes things more insecure.

So now an unprivileged app can masquerade as a apache or imapd.

Re:So, speaking of security,

[Homology]

Well, sure, but that doesn't to squat for security -- it just makes things more insecure. So now an unprivileged app can masquerade as a apache or imapd.

You do not understand the issue : Too many daemons runs as root just beacuse they need to bind to a low port. So any exploit will be a remote root exploit. Besides, if you rely on port numbers for security on random machines, I guess you have some problems ;-)

Re:So, speaking of security,

[hey!]

No offense taken, I do understand the problem. It's just that the problem of security never boils down to one thing, does it.

It isn't just about a daemon getting root privileges. That's really bad of course. But impersonating a trusted program is really bad to, just not quite as bad. When the trusted program can bind to the port, and only that program, it solves both aspects of that particular problem.

Oh, there's lots more ways we can get in trouble, but every door that's closed and locked is a good th

Re:So, speaking of security,

[dmiller]

It may be more accurate to say that "too many programs start as root because they need to bind to a low port", but most of them give up root privileges quickly (at least on OpenBSD).

Re:So, speaking of security,

[evilviper]

"too many programs start as root because they need to bind to a low port", but most of them give up root privileges quickly

While that's true, it's far from ideal. There have been many instances where popular apps (eg samba) that were supposed to drop root privlidges immediately, didn't do so properly, and became a remote root exploit anyhow...

Re:Gripes.

[niteice]

IIRC, Dreamcasts have a CD drive that spins backwards. YOu ned to rewire your CD burner.