Subject: Re: Preventative security features?
To: None <tech-security@NetBSD.org>
From: Dmitri Nikulin <setagllib@optusnet.com.au>
List: tech-security
Date: 11/15/2004 22:51:11
Simon Hitzemann wrote:

>Most people unfortunately think that no answer means that there is
>nothing here. That's wrong. If there is no answer on a SYN request or
>UDP packet, it means there is some packetfilter dropping packets. If
>that port was nonexistent as in there is no machine, then the router
>before that machine would have to answer.
>
>  
>
Oh... crud. Well so much for my theories. This is what you get for 
listening to Steve Gibson (grc.com)

>Other ideas like randomizing things are ok but not really urgent.
>I am also a bit indifferent about TTY snooping, privacy vs security is
>always a hard decision if you want to keep your users productive.
>  
>
If they object to it, turn it off. I don't see why implementing a 
potentially life-saving feature that can be used to invade privacy (what 
work would users have to hide anyway?) is really such a problem. It can 
be disabled if it's company/organization policy anyway. Does this mean 
FreeBSD on shared servers is a bad idea because root might have compiled 
in snp(4) or at least a module? If people really felt this way then 
there wouldn't be so many shell servers running FreeBSD. On the other 
hand, and is the case I'm arguing, it can be used to watch a local 
attacker in action, and not only be able to prevent it by taking over 
his terminal, but indeed learn what attackers are trying, to prevent 
even the possibility. Why NOT implement this?

>Maybe it would be more interesting to implement ACLs for UFS2 as those
>would have a larger impact on security in my opinion.
>  
>
Really? My idea has always been that the simplest security design that 
covers necessary aspects is the most secure one possible. The more you 
complicate things - packet filter rules, ACLs, etc. - the more chances 
there are that somebody will find a loophole. Think of all the code that 
is found to be crackable just because it was over-complicated and all 
possible routes of operation weren't considered.

ACLs are useful if you know what you're doing, of course, but I wouldn't 
call them a boost in security on their own. They open up paths to big 
mistakes.

>Best regards,
>Simon
>  
>
Best regards,
Dmitri

PS: One thing I wanted to ask but isn't documented in the manpage, is 
the default chown/chmod behavior to follow or not follow symlinks? If 
follow, I'm imagining this situation:

ln -s /root ~/code
write root
Having ownership confusions here. Can you please chown -R my home dir? 
Thanks.
^D
<wait>
cd ~/code/
<something unspeakable>

And so on. Of course if a newbie root doesn't check every flag he's 
about to use, and is told to run chown -RL, it won't matter what the 
default is.