[prev in list] [next in list] [prev in thread] [next in thread] 

List:       best-of-security
Subject:    Re: SunOS vs Solaris 2 vs Intel/BSD for firewalls
From:       Julian Assange <proff () suburbia ! net>
Date:       1995-08-11 6:49:21
[Download RAW message or body]

Forwarded message:
>From firewalls-owner@GreatCircle.COM Fri Aug 11 15:11:28 1995
Message-Id: <9508101726.AA26472@ig1.att.att.com>
From: mdr@vodka.sse.att.com
Subject: Re: SunOS vs Solaris 2 vs Intel/BSD for firewalls
To: mjr@iwi.com
Date: Thu, 10 Aug 1995 13:27:54 -0400 (EDT)
Cc: firewalls@greatcircle.com
In-Reply-To: <199508101559.LAA13701@switchblade.iwi.com> from "Marcus J. Ranum" at Aug 10, 95 11:59:11 am
X-Mailer: ELM [version 2.4 PL23-upenn2.7]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: firewalls-owner@GreatCircle.COM
Precedence: bulk

Marcus,

> 
> 	The idea of immutable files is pretty sound, and the guys
> who did it have thought it through pretty thoroughly.
> 
> mjr.
> 

Thankyou for the excellent information on bsd.  Looks like they put some
thought into it, that's good to see.  So writing /dev/kmem or the raw
divices won't work.  Let me try a few more jabs at it if you don't mind, 
before we call it a security feature.

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!

Would all of the cron scripts and rc scripts and network startup
scripts also be immutable? 
If I can affect any file that root runs during single user mode, I can
still hack the system, I just have to wait for a re-boot.  Hmmm, can I
force a re-boot?  Hmmm, can I fill up the var file system, or is that 
immutable too! :)  I'll just write to the tcp log files, surely the
log files aren't immutable or unappendable.  Denial of service attacks abound.

Can I unlink and replace an immutable file if the directory is not 
immutable? (I bet that they thought of that one, it's too easy)

Unless you limit the root user to the console in single user mode
(which I bet they don't really do) some admin type has probably built a
backdoor into the system for me already.  /etc/rc2.d/S99update would
do the trick.  Do the packadd scripts do delayed updates? They've
probably got a hook somewhere too.

Maybe I'll just lay a T.H. around for root to trip over.  Is the 'ls'
command immutable?

By the time you get around to locking all of the files that have to be
immutable, you might as well make /, /var and /usr (please sub in bsd
equivalent names) readonly file systems.  Ouch!

How does init ever go back to init state 1 ? Or is that disallowed
too.  If not, what secret does init know for changing the run state that root
a root user can't do. Can I fool the system into thinking that it's
back in init state 1?  Is the init process protected from modifications 
by a process debugger?  Is /dev/swap immutable?  Forcing a reboot from 
scratch for every (even trivial admin) would work, but ouch! that hurts too!

The immutable file concept may be more security speak than security feature.  
It might not work at all, but if it does it might hurt too much to
use.

A B1 system can protect all of the TCB by only allowing level 1 logins 
and level 1 network daemons while in multi user mode.  The TCB is
maintained at level 0.   But the system can still be maintained in 
multiuser mode at the console or by dailin over a secure modem, or if 
the host is also a firewall you could limit level 0 logins to a secure 
interface and encrypted link.  Each device and user has a clearance 
associated with it and both the device and the user must be cleared 
to level 0 before they can su to root.  (Login as root is disallowed 
at C2 and higher, because it violates I&A, being an anonymous login)

Hmmm, all of the useless B1 stuff sure is starting to sound nice.

Can the user write /dev/kmem or /dev/dsk/xxx ?  No they can't even see
them!  How about /unix ? Manditory policy protects it.  Can they
become root? Sorry tty device not cleared!  Can they trip root?
`>/tmp/ls` just creats a file that's labeled level 1, and root can't exec
level 1 code because its not trusted.  Modify config files?  manditory
policy protects them all.   It's nice to have a model that hundreds of
people have looked at.

Mark Riggins
Secure Systems Engineering 
AT&T Bell Labs

PS:
> 	[It's /bsd, not /unix. UNIX is a trademark of somebody or
> other and they used to sue people over that distinction. :)]

bsd??? never heard of it, we only run operating systems named after
bad movies or single clergy ;)  Seriously, I'd like to learn more
about bsd, but its hard enough to stay up-to-date on my current scope.
And thanks again for the info.

[prev in list] [next in list] [prev in thread] [next in thread]