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.