Date: Thu, 23 Oct 1997 14:09:08 +0100 From: Colman Reilly <careilly@monoid.cs.tcd.ie> To: hackers@FreeBSD.ORG Subject: Security Policies [Was: ACLs [Was: C2 Trusted FreeBSD?] ] Message-ID: <199710231309.OAA04169@monoid.cs.tcd.ie> In-Reply-To: Your message dated today at 09:28.
next in thread | raw e-mail | index | archive | help
[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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710231309.OAA04169>