From kragen@dnaco.net Wed Sep 30 12:12:17 1998 Date: Wed, 30 Sep 1998 12:12:16 -0400 (EDT) From: Kragen To: Mitchell Blank Jr cc: Chris Evans , "Stephen C. Tweedie" , Paul Boehm , security-audit@ferret.lmh.ox.ac.uk Subject: Re: rootd In-Reply-To: <19980930105841.21566@execpc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: On Wed, 30 Sep 1998, Mitchell Blank Jr wrote: > Kragen wrote: > > Mandatory access controls cannot be implemented; > > Only if you define them to mean "other than what UNIX does now". It's true > that this could use improvement (see below) Unix does not have any mandatory access controls. > > information leakage is impossible to prevent; > > That's always true. ALWAYS. No, it is not. > > jailing possibly-compromised processes > > is essentially impossible. > > chroot+nonroot is a good jail. Could be better. chroot+nonroot has the major problem that only root can do it. > > The approaches that offer the most toward > > solving these problems are basically complete replacements for the Unix > > security model. Mandatory access controls and jailing > > possibly-compromised processes (which are really the same thing) gets > > done by writing a system-call monitor. > > Which we can do now, in userland. Yes. The point is that it essentially replaces most of the Unix security model with a brand new one. (Accesses that the kernel would gladly permit get denied, based on a set of criteria almost totally unrelated to the set of criteria the kernel would use to make access decisions. Given a working system-call monitor, you could safely turn off all the kernel access control and you'd be safe.) > > Fixing denials of service means > > changing scheduling and memory allocation to use beancounter objects. > > Which Alan has done some good work on, and will hopefully be a centerpiece > of the 2.3 kernel. Yes, I know. Again, it replaces part of the Unix security model with a brand new one. > > Auditing everything damn thoroughly is the plug-all-the-holes approach, > > also known as the "Microsoft approach to building bug-free software". > > It is not very effective. > > It's very effective. Just also very hard. It's very error-prone, which is OK in most things, but in security, 'error-prone' translates to 'ineffective'. > > The interface between the totally untrusted > > world (people who send you email, for example) and authenticated local > > users is even worse, and will probably stay that way. > > That is a good point. I think the janus-style-jailing would be a big > improvement in this regard. I wonder what we could do as far as > improving ptrace(2) to make janus faster/easier, especially in the > case where you are tracing many processes. Ask David Wagner. There are several pages in his draft thesis that answer that question. Basically, ptrace() doesn't let you deny system calls, except through a fiendishly complex scheme I cooked up that involves sending lots of signals and writing lots of 'invisible' code into the address space of the process that's being traced. Also, ptrace() doesn't let you permit certain system calls without consulting the security monitor -- read() and write(), for example, are always safe. This is just an efficiency concern. Also, if the monitor process fails, the monitored process goes free. This is bad, because it's fail-open. > (sounds like another good use for doors... what a coincidence) What, exactly, are 'doors'? *interest* Kragen -- Kragen Sitaker A well designed system must take people into account. . . . It's hard to build a system that provides strong authentication on top of systems that can be penetrated by knowing someone's mother's maiden name. -- Schneier