Stephen Goldstein writes:
> >How do they administer the system in mulituser mode? Presumably adding
> >users and accounts and such would be disallowed. Also adding undesired
> >services such as a telnetd or packet grabber would be disallowed.
> >
> >Ok then, no maintenance while in multi-user mode. Ouch!
>
> I thought we were discussing the benefits of immutable flags for use
> in securing Firewall boxes. In that context, there are (or should be)
> no user accounts that might require administration in multi-user mode.
> Further, I see the requirement of going to single user mode before the
> configuration can be changed as a real plus.
Oops, I didn't mean to add useradm to the list (although hardened
servers are more capable of supporting user accounts safely).
The administration that I meant to refer to is that of the firewall
itself, ie, what types of services to allow. This immutable file concept
kicks in at multiuser mode, which means that the most important files
get locked down while the system is multiuser. On the surface that
sounds good. But going single user means that all services have to
stop everytime you make a change. If your firewall is in a production
environment, that's not always a good idea. Also you have to reboot
the system to get back to an administratable run level, so you might
be down for a considerable time to make a trivial change. Also,
remote administration will be more difficult in single user mode,
although some products do attempt solutions there.
The real plus is being able to change the configuration in a secure
manner. There are better ways to do that than relying on immutable
files. One way is to use B1 to protect all configuration data and
binaries from user processes such as proxies and such. This type of
protection allows you to change them while the system is in multiuser mode.
If you want to, you can even limit the access to these files to a session
that has to start on the console. On the other hand you could allow
an administrative session to begin only from a trusted interface
connected to only a few machines and otherwise inaccessible. That's
more of a risk but some would choose to make that tradeoff.
I like the idea of an append-only flag which bsd offers. That makes
sense for log files and such as long as they don't grow to large. But
if you run out of space, you'll have to reboot to archive and truncate the
log files. In our B1 system, regular processes cannot
read/write/truncate/append or even see the log files. Logging
information can be written in an append only fashion to a special
device file similar to /dev/log, that records the date/time/pid
of the writer along with the data. On an immutable system, recording
the log file over the net via syslogd may make more sense.
Don't mean to drone on here. Just hate to see the lack of interest in
B level systems when they have so much to offer as hosts for firewalls.
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
References:
|
|
