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.