From owner-freebsd-security Mon Oct 13 14:16:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24566 for security-outgoing; Mon, 13 Oct 1997 14:16:38 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA24552; Mon, 13 Oct 1997 14:16:31 -0700 (PDT) (envelope-from brian@shell.firehouse.net) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id RAA24215; Mon, 13 Oct 1997 17:15:59 -0400 (EDT) Date: Mon, 13 Oct 1997 17:15:55 -0400 (EDT) From: Brian Mitchell To: Christopher Petrilli cc: Colman Reilly , Douglas Carmichael , freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710132110.RAA29578@dworkin.amber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 13 Oct 1997, Christopher Petrilli wrote: > >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. no, it isnt. make a group, put users that cant access it in the group, chmod g-rwx file bang, groups are perfectly able of supporting the needed dac > > 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. > yah, when we release something back into a system, we have to bzero() the contents, or something similar. > 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 :-) > I think it is useful as well, I just dont think it is a c2 requirement.