From owner-freebsd-hackers Mon Oct 13 14:11:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24142 for hackers-outgoing; Mon, 13 Oct 1997 14:11:51 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from dworkin.amber.org (mail@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA24104; Mon, 13 Oct 1997 14:11:35 -0700 (PDT) (envelope-from petrilli@dworkin.amber.org) Received: (from mail@localhost) by dworkin.amber.org (8.8.7/8.8.7) id RAA29578; Mon, 13 Oct 1997 17:10:39 -0400 (EDT) Message-Id: <199710132110.RAA29578@dworkin.amber.org> X-Authentication-Warning: dworkin.amber.org: mail set sender to using -f Received: from ab1-02.dial.nova.org(209.31.144.162) by dworkin.amber.org via smap (V1.3) id sma029575; Mon Oct 13 17:10:34 1997 Subject: Re: C2 Trusted FreeBSD? Date: Mon, 13 Oct 97 17:09:09 -0400 x-sender: petrilli@dworkin.amber.org x-mailer: Claris Emailer 2.0, March 15, 1997 From: Christopher Petrilli To: "Brian Mitchell" , "Colman Reilly" cc: "Douglas Carmichael" , , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I'm fairly certain acl is _not_ a requirement in the dcl segment of c2. >acl is, after all, just another form of group control at its very base. It is not "mandatory," however the following paragraph exerpted from the TCSEC does make it clear that the exisintg group mechanism is NOT acceptable: "The access controls shall be capable of including or excluding access to the granulairty of a single user." This exclusion part is what makes it very difficult. You must be capable of giving access to everyone BUT a specific user. While theoretically I guess you could do it by managing billions of sepereate groups, I think it would fail none the less because of practical enforcement concerns. THat having been said, there is one other requirement that would need to be addressed: * Object Reuse (2.2.1.2) THis is defined as follows: "All authorizations to the information contained iwthin a storage object shall be revoked prior to initial assignment, allocation or reallocation to a subject from the TCB's pool of unused storage objects. No information, including encrypted representations of information, produced by a prior subject's actions is to be available to any subject that obtains access to an object that has been released back to the system." Basically, we need to purge all memor when it is allocated, or deallocated. Other than that, it's mostly documentation, and audit. I would really prefer to do an ACL extension to the file system, as I think it's useful as it is :-) Chris -- | Christopher Petrilli "That's right you're | petrilli@amber.org not from Texas."