Subject: Re: Preventative security features?
To: None <tech-security@netbsd.org>
From: Dmitri Nikulin <setagllib@optusnet.com.au>
List: tech-security
Date: 11/13/2004 16:45:38
Jaromir Dolecek wrote:
>Dmitri Nikulin wrote:
>
>
>>Is there any reason NetBSD doesn't implement many preventative security
>>features?
>>
>>
>
>Why do you think so - can you privide any examples of particular
>security feature you'd like to see in NetBSD?
>
>
>
>>Is there a reason these things (blackholes, randomization of kernel
>>data, etc) aren't done in NetBSD? If not, does anybody object to work
>>done to bring them in to -current? I'd certainly like features like
>>that, even if I have to code them myself.
>>
>>
>
>Useful additions are always welcome :) But don't get yourself
>fooled into thinking that certain things a bit more random provides
>any security benefit.
>
>
>
>>At the very least, the ability to run nmap against a NetBSD machine and
>>have it be completely unknown, even with plenty of open and closed ports
>>available. Free and OpenBSD can do this just with a few sysctl runs,
>>Linux stands no chance, but NetBSD should be up with its brothers and
>>not alongside Linux.
>>
>>
>
>Why would anonymizing be any useful? Security by obscurity?
>
>Jaromir
>
>
Jaromir? Pleased to meet you, I use your old sig (reference to Buddhist
masters' comments) on a public forum. With credit of where I found it :)
Randomizing PIDs doesn't seem that useful (unless somebody can argue
this), but TCP sequence numbers (Free and OpenBSD get a maximally hard
score, NetBSD doesn't) and all that /could/ be useful. Of course this
has to be done without any ghastly overhead that would add a lot of
latency to packet generation.
Anonymizing is useful though. If there is some exploit released that
affects only some systems and NetBSD is one of the few, then the time
between the exploit being known and being patched is when any system
advertising itself as NetBSD is more likely to be targetted by some
lamer. Of course on the other hand they could just waste time hammering
every system out there and hoping something worked. But basically the
idea is, if they don't know the system, they don't know the exploits.
While I'm sure we may all run into the streets advertising that our
servers/toasters run NetBSD, it's probably not the best idea :)
Besides, anonymizing tends to come as a side effect of generally
unpredictable packeting, which has other advantages in that attackers
can't find loopholes ahead of time, or worse yet introduce them by some
means. It also gives them less insight into what the system is doing
(for instance, watching the rate at which counters are incremented to
tell how much other load the system is enduring, and so deciding if a
DoS is worth it).
One thing that is definitely a very good privacy/security feature is
what FreeBSD implemented that can prevent users seeing the PIDs (or
indeed any info) of processes they don't own, via ps or top or whatever
else. Nobody can argue that this is a Good Thing on a shared shell
server. Whether or not this is easy to implement cleanly is another matter.
Yet one other thing that FreeBSD has that NetBSD (well, every other
system) doesn't is tty snooping. For those that haven't tried it, it's
roughly equivalent to 'screen -x' but to any tty, so you can silently
stalk or manipulate users. I find this really handy to give interactive
tutorials into Unix usage to newbies without having to re-ask at every
moment "well what's happening?" and without having to tell them to run
screen. Of course the security of watching for attempts at local
exploits is a huge benefit too. If THIS could be implemented cleanly
(possibly as a hook into wscons itself, instead of the snp(4) hack
FreeBSD has) it'd be a great thing to have handy. We could even go
further and have a daemon using this facility to actively watch for
certain regexps or things that could lead to a local exploit or
generally Bad Thing, make a dump, lock their terminal, and inform root
via write(1) or email. Endless possibilities really.
My real point is, NetBSD has portability and now even awesome
performance (and passive security of course), why not branch out into
proactive security too? It could be the "something for everyone" system
that is actually good and clean, not like some others.