suid bit files and securing FreeBSD

[Chuck Swiger]

Peter Rosa wrote:
[ ... ]
> I'm looking for an exact list of files, which:
> 1. MUST have...
> 2. HAVE FROM BSD INSTALLATION...
> 3. DO NOT NEED...
> 4. NEVER MAY...
> ...the suid-bit set.
> 
> Of course, it's no problem to find-out which files ALREADY HAS
> suid-bit set. But what files REALLY MUST have it ?

The files which ship setuid "REALLY MUST" have the setuid-bit for the underlying 
programs to work normally for a non-root user.  If you don't care about non-root 
users having a normal environment, you can probably remove the setuid-bit from 
every program.

[ Things like 'su' won't function, nor will 'ping', any utility like ps, 
netstat, etc which grovel in kernel data structures, etc. ]

> I know generalities, as e.g. shell should never have suid bit set,
> but what if someone has copied any shell to some other location
> and have set the suid bit ? It's security hole, isn't it ?

Yes.

> And what if I have more such files on my machine ?

You would have more security holes.

> It is not about my machine has been compromited, it is only WHAT IF...
> 
> --------------------------------------------
> 
> Second question is: Has anybody an exact wizard, how to secure
> the FreeBSD machine. Imagine the situation, the only person who 
> can do anything on that machine is me, and nobody other. I have 
> set very restrictive firewalling, I have removed ALL tty's except 
> two local tty's (I need to work on that machine), but there are 
> still open port 25 and 53 (must be forever), so someone very 
> tricky can compromite my machine. 

Disconnect the machine from the network and lock it in a vault: that's a secure 
system.  If you can't do that, say because you need to run network services on 
this system, then you need to stay up-to-date with regard to those services, and 
upgrade or apply patches as appropriate, ie, if a security hole is announced.

Contorting the system in the fashion you describe gives little security benefit.

-- 
-Chuck