Date: Tue, 14 Oct 1997 15:16:19 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Aleph One <aleph1@dfw.net> Cc: freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? Message-ID: <Pine.BSF.3.96.971014150845.1711A-100000@cyrus.watson.org> In-Reply-To: <Pine.SUN.3.94.971014124854.10817A-100000@dfw.dfw.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Oct 1997, Aleph One wrote: > 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. This is not entirely true; alternative distributed file systems (such as AFS) provide an ACL protection system, and even differing file semantics (last-close not last-write) yet most applications work correctly. ls is minorly-modified so as to ignore non-user permissions (AFS, as I understand it, does maintain user rwx, etc, just not for others.) Many applications do not interact much with protections; they will set permissions on newly created files, but those may safely be ignored (well, not safely, but that is the user's problem: they should know the semantics of the file system they are working on?); permission changes can be largely ignored (except on user permissions for execute support.) Setuid is a weird one and would require some thinking out. Using the ptserver support, you get user defined groups and all kinds of useful things. That only system administrators can maintain groups under UNIX has long been a gripe I've had :). The ability to do the following on AFS is very useful, and interfaces well with WWW stuff: fs sa . rnw all system:authuser rl system:anyuser none meaning that all authenticated users can access the directory, but users not authenticated to kerberos cannot (i.e., web servers on workstations that don't have authentication.) Similarly, user's can create their own groups and refer to them easily; I can create rnw:friends and give them read, delete, insert access on the directory, but leave out anyone not in friends. I can also use negative access rights to specifically deny users access to a directory. My main gripe with ACLs has been the inheritence and management issue -- individual ACLs on each file are almost impossible to maintain, and very hard to list in any useful way in a directory listing. Applying ACLs only to directories themselves makes for easy management, but is this allowed by the various security specifications? Must we provide individual-file permission support? Do the specifications allow us to use standard UNIX permissions for some partitions, and reserve ACL permissions for user and data partitions? The by-directory ACL scheme does not work so well for /dev, for example! Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971014150845.1711A-100000>