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 20:23:57
Jaromir Dolecek wrote:

> Dmitri Nikulin wrote:
>  
>
>> 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.
>>   
>
>
> IIRC we do randomize TCP sequence numbers.
>
>  
>
Maybe just not enough, then :)
Is this fed from the high-quality random source? nmap didn't give up all 
hope on it.

On a related note, on my old Intel i815 chipset which has a hardware 
RNG, NetBSD says it enables it at boot, but what does it do from there? 
Does this get read from into the system's entropy pool or what?

>> 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.
>>   
>
>
> Arguably, it's about as hard to try the exploit as to run nmap
> against the machine.
>  
>
But you only need to run nmap once :)
And only one person needs to do it ever, then post to a "l33t skr1pt 
k1733z" forum. Of course this is just being really pessimal.

>
>  
>
>> 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.
>>   
>
>
> This might indeed be useful. I had a look into this, and it seems
> this could easily be implemented with one condition in
> init_sysctl.c:sysctl_doeproc(), plus some sysctl machinery
> to export setting to userland.
>  
>
That simple? Should be tried at once then. It's certainly something with 
a high usefulness-to-code ratio.

>> 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.
>>   
>
>
> This also seems useful. I think it wouldn't be too hard to implement
> using some 'intercept' hook in tty layer.
>
> Jaromir
>  
>
Yeah, that's exactly what I thought, but how to export from there is 
more interesting. We should investigate how FreeBSD does it, and then do 
it completely differently. Their way uses a different virtual device, 
which really is a hackish solution since the functionality can be 
integrated into the tty layer (okay, yeah, what was I thinking saying 
wscons?) and possibly left as a compile-time option.