From owner-freebsd-security  Sun Jul  6 17:14:33 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id RAA13091
          for security-outgoing; Sun, 6 Jul 1997 17:14:33 -0700 (PDT)
Received: (from jmb@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id RAA13078;
          Sun, 6 Jul 1997 17:14:12 -0700 (PDT)
From: "Jonathan M. Bresler" <jmb>
Message-Id: <199707070014.RAA13078@hub.freebsd.org>
Subject: Re: Security Model/Target for FreeBSD or 4.4?
To: brian@firehouse.net (Brian Mitchell)
Date: Sun, 6 Jul 1997 17:14:11 -0700 (PDT)
Cc: jmb@FreeBSD.ORG, jkh@time.cdrom.com, careilly@monoid.cs.tcd.ie,
        adam@homeport.org, freebsd-security@FreeBSD.ORG
In-Reply-To: <Pine.BSI.3.95.970706181825.13456A-100000@shell.firehouse.net> from "Brian Mitchell" at Jul 6, 97 06:21:13 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Brian Mitchell wrote:
> 
> On Sun, 6 Jul 1997, Jonathan M. Bresler wrote:
> 
> > Jordan K. Hubbard wrote:
> > 	in a nutshell,	the security model is 
> > 		"you must have permission to do something".
> > 		the superuser (aka root: uid 0) is can do anything.
> > 		command audit trail (logging) is not provided. 
> > 	the holes have been in the implementation of that model.
> > 	the source shows the implementation.  which has been of greatly
> > 	varying quality regarding security. ;(
> > jmb
> > 
> 
> I'm not sure that's entirely corrent - superuser, for instance, can not

	a nutshell is never entirely correct.
	securelevels were introduced in 4.4BSD, if i remember correctly.
	they are an innovation

> (with the exception of holes in various subsystems...) lower the
> securelevel. I'm not sure what you mean by command audit trail, but
> process accounting is available, and is pretty darned close to logging

	command logging is one example of the more rigorous control
	that some other systems have.  mind they are a royal pain.
	they remember ever passwd you have used for xx months and 
	refuse all attempts to re-use them, while at teh same time 
	expiring passwords every xx days.  but no one uses reuseable 
	passwords anymore, right ;)

jmb

> commands. Stuff like syscall level accounting such as available in sun's
> bsm stuff is, unfortunately, not available presently.