I've got a unix-centric firewall related question. Is there any
reason to keep any UID 0 users on the firewall gateway box?
Binding processes to ports < 1024 is not a problem. I tracked
down and quickly browsed through the bind() syscall implementation in
the FreeBSD kernel and didn't find anything which would prohibit me
from either removing the concept of 'privileged port' completely or
allowing some user ID other than 0 to bind to such ports without
opening up anything else. I suspect this is fairly typical of unixish
kernels in general.
Maintenance could all be done by rebooting the firewall in single
user mode. Rebooting itself is easy enough to do if all disk
partitions are normally mounted read-only -- just tell Eeeegor to
fleep zee sveeech.
The general concept I'm kicking around is having the boot rc file
execution process become un-root at some point after mounting disks
and doing similar burly root things, but before firing off any
bloated potentially security hole laden processes like inetd. Once
the UID of 0 is shed, there wouldn't be any way to get it back.
Given a complete lack of setuid 0 executables on the machine, of
My reasoning is that even if some maladjusted bozo is able to use
an obscure back door in inetd's 'echo' implementation to get at
a shell on my gateway, it wouldn't help them. The read & execute
permissions throughout the machine would be set up to deny everything
with extreme prejudice.
Our hypothetical cretin would be completely prohibited from running
anything other than inetd and proxy services. Including the shell
in the first place. Come to think of it, there's no need for PTY
support either. The frustration level of beating on such a mutant
setup should be enough to make the aforementioned cretin take a
chainsaw to a nearby playground instead.
Am I overlooking anything fundamental? Has anyone tried a similar
unixotomy? This approach seems like it would make the gateway
MUCH more secure at the minor added frustration of having to be
present at the console to maintain the machine.