From owner-freebsd-hackers Thu Oct 23 06:09:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA24057 for hackers-outgoing; Thu, 23 Oct 1997 06:09:51 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA24049 for ; Thu, 23 Oct 1997 06:09:48 -0700 (PDT) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id OAA04169 for ; Thu, 23 Oct 1997 14:09:08 +0100 (IST) Message-Id: <199710231309.OAA04169@monoid.cs.tcd.ie> To: hackers@FreeBSD.ORG Subject: Security Policies [Was: ACLs [Was: C2 Trusted FreeBSD?] ] X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Your message dated today at 09:28. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4164.877612147.1@monoid.cs.tcd.ie> Content-Description: text Date: Thu, 23 Oct 1997 14:09:08 +0100 From: Colman Reilly Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Deleted discussion about how difficult ACLs are to implement in UNIX] The basic problem with implementing ACLs, multi-level labelling and so on is that FreeBSD has very little support for security policies. It's not really a part of the architecture and seems to be done on an ad hoc basis subsystem by subsystem. I think we'd be better off considering a more general solution rather than trying to hack support in on a case by case basis. So to this weeks insane plot; A layered security model, similiar in conception to the layered filesystem, which allows a choice of access control models or model and which is used by all subsystems to make access control decisions. This way an installation could choose between (say) standard UNIX access control, ACL based access control, MAC style multi-level access control or role based access control or combinations thereof. It would also allow for more specialised access control models to be plugged in, and for the layers to be used on a system by system basis, so that the news directory was using standard UNIX access control while user directories were using ACLs on top of MAC based controls. The system would also be able to control things other than files - it could give us the socket level controls suggested previously, and possibly access controls on processes, so that unpriviledged users could send signals to daemons, that sort of thing. The main problem see (beyond the size of the task!) is where to store the access control information. The system tools would need to be changed, but thats doable - that's why we have a full distribution rather than just a kernel. We should be able to wrap most of the required stuff into a library to make changes easier. Third party tools are more of a problem. How many of them will have problems? Should we expect tar to handle this information? Does tar know how to preserve ownership even now? Colman, rambling again.