From owner-freebsd-hackers Mon Oct 13 12:30:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17303 for hackers-outgoing; Mon, 13 Oct 1997 12:30:51 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17288 for ; Mon, 13 Oct 1997 12:30:39 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (node22.tfs.net [207.2.220.22]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id OAA23500; Mon, 13 Oct 1997 14:29:06 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id OAA01709; Mon, 13 Oct 1997 14:29:15 -0500 (CDT) From: Jim Bryant Message-Id: <199710131929.OAA01709@argus.tfs.net> Subject: Re: C2 Trusted FreeBSD? In-Reply-To: from Brian Mitchell at "Oct 13, 97 01:46:02 pm" To: brian@firehouse.net (Brian Mitchell) Date: Mon, 13 Oct 1997 14:29:14 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > > Well, certainly it could achieve C2, though we would need to do a *lot* of > > documentation and testing work, and we may need to include an ACL list based > > filesystem, that depends on your reading of the Orange Book. I'm not > > experienced enough to tell what the "normal" interpretation of the > > requirement that access should be controllable down to the granularity of a > > single user is. In principle one can deny access to an object by creating a > > group with everyone except that user in it and set that to be the object's group > > but I'm not sure a certification group would consider that adequate. > > 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. certification or not, i personally think that acl-based object access is something that would work in FreeBSD's favor, especially given the now infamous unix-slam from nt fans on the subject... such a thing is needed if unix is to evolve with the market. right now, i really think that acl security is one of the few technical things that nt has going for it. > Yup, this is one of the biggest problems. You cant write to an object > unless it has a security level that is precisely the same. You can only > read unless it is the same or lower. Most people don't come close to > needing B level security; and it is arguable if it is useful for > commercial systems at all. lotsa applications. healthcare, process control, telecom... High Availability drivers would be a plus too... > > Now, if we introduce such things we get a somewhat different view of the > > world than the traditional UNIX-like security model. I do not know if it > > possible to maintain a good enough match to enable us to continue to easily > > port UNIX based software to FreeBSD. > > > Most unix admins dont easily give up the whole idea of the superuser, > which would probably be required for B level. the way i read it, a compatability mode is not addressed by the standards, and thus could possibly pass certification. such a mode would be an absolute necessity for the above mentioned reasons. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+