From owner-freebsd-security Tue Oct 14 10:53:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA05535 for security-outgoing; Tue, 14 Oct 1997 10:53:53 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dfw.dfw.net (aleph1@DFW.DFW.NET [198.175.15.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA05522 for ; Tue, 14 Oct 1997 10:53:49 -0700 (PDT) (envelope-from aleph1@dfw.net) Received: from localhost by dfw.dfw.net (4.1/SMI-4.1) id AA11295; Tue, 14 Oct 97 12:54:35 CDT Date: Tue, 14 Oct 1997 12:54:34 -0500 (CDT) From: Aleph One To: Brian Beattie Cc: Colman Reilly , Douglas Carmichael , freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: 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 Tue, 14 Oct 1997, Brian Beattie wrote: > Most of the people involved in INFOSEC are absolutely "head over heals" in > love with ACL's, big ACL's. I am not convinced of their utility in the > real world, especially with suplementary groups. If I were designing a B1 > UNIX system I would not change the current access control design. The problem with ACL's is not it's nature but the fact that if you implement them under UNIX nothing knows how to candle them. For example you would need to modify ls to show them, you need to modify cp to copy them, you programs need to be aware of ACL directory inheritance, etc. This is not a problem when you are designing a new OS and people will have to learn the new API (e.g. Windows NT) but if you are trying to maintain compatibility with other unixes or try to port random programs it becomes a pain. HP-UX has had ACLs for quite some time now but not one uses them just because of this. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01