Date: Tue, 7 Dec 1999 10:40:45 +0300 (MSK) From: "Ilmar S. Habibulin" <ilmar@ints.ru> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL-0.1.1.tgz: updated for -CURRENT, some bugfixes Message-ID: <Pine.BSF.4.21.9912071028190.5153-100000@ws-ilmar.ints.ru> In-Reply-To: <Pine.BSF.3.96.991206183755.12192D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. PS. What does freebsd project leaders think about all that posix stuff and our efforts? 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.4.21.9912071028190.5153-100000>