Date: Tue, 7 Dec 1999 10:27:37 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: "Ilmar S. Habibulin" <ilmar@ints.ru> Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL-0.1.1.tgz: updated for -CURRENT, some bugfixes Message-ID: <Pine.BSF.3.96.991207101916.16441D-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.9912071028190.5153-100000@ws-ilmar.ints.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Dec 1999, Ilmar S. Habibulin wrote: > On Mon, 6 Dec 1999, Robert Watson wrote: > > > As you may have seen in my recent post, I agree that disk storage is > > something we need to address ASAP, and the best approach is probably > > extended attributes. I'd like to see support for ACL, CAP and MAC in the > > VFS interface directly, however, and finalize that API in time for the 4.0 > > feature freeze, even if we don't get storage ready by 4.0. > It would be centralized development, not just incoherent patches. And > there would be very nice to reimplement access control scheme in > freebsd. Do some reference monitor. The problem with a cvs repository of our own is that then we have to intermittently synch with the central repository and lose our repository history (I don't believe CVS easily allowed for parallel vendor development trees which pick up both sets of changes?) Once I get a first useful version of ACLs out the door for -current in the next few days, I'd be willing to move to this, however. > > In the extended attribute scheme, these would be backed onto the extattr > > vop calls, although the syscall code on top would not see that > > happening--meaning that ACLs are visible in the VFS scheme, not just > > attributes (which would also be visible in VFS). > > > > Does this make sense to you? > I don't know. The thing is that MAC differs from DAC too much. It have > another aproach of getiing/setting labels, so sometimes mac label should > not be visiable or settable. If we can reserve some space, that would be > accessed only by the kernel through vop_extattr interface, and everything > else would be accessable from the userspace through this interace. I'm > afraid, that MAC implemetation without such limits will beak the > NoWriteDown rule of BLMs' MAC. In a more recent post (I think just to -arch) I outlined a possible access control mechanism for the attributes. This largely consisted of a flag which chose between "owner-writables/readable" and "kernel-writable/readable", the idea being that in the first mode, modification to the attributes via standard attribute syscalls would be permitted (within the limitations imposed by the fs mount status and permission set, such as read-only), but in the second mode it would be appropriate for storing security-sensitive information such as DAC and MAC information, as it would be neither modifiable nor readable by userland processes, except through the vops in kernel. This flag (still in the proposed stage) would be set per-file system, per-attribute, and would be declared when that attribute was initially configured for the file system. > PS. What does freebsd project leaders think about all that posix stuff and > our efforts? My impression has been that ACLs, capabilities, and auditing are of great interest. I haven't seen all that much interest in MAC, but I'm sure once people see the possibilities, they will be more interested. (For those reading and wondering, one possible answer is to assign a MAC level to each securelevel, and now objects associated with that securelevel are now immune to modifications by higher securelevels in an integrity model -- unlike the noschg flag, this has well defined semantics for how to modify and not modify files in various process environments, what processes may debug/not debug other processes, etc. This would require an explicit declassification process, but I'm sure we can think it through more once we have the facility). So as such, my impression is the answer is "supportive and interested", but perhaps someone reading this could enlighten us :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991207101916.16441D-100000>