Date: Wed, 8 Dec 1999 08:15:13 +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.9912080757070.33108-100000@ws-ilmar.ints.ru> In-Reply-To: <Pine.BSF.3.96.991207101916.16441D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Dec 1999, Robert Watson wrote: > > > 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. I think that there would be much more better and easy to use freebsd cvs. I do not need this cvs direct access, but the technique, that will allow me to send my updates and get them included in -current, plus i should have my sources always -current. > 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. Very nice solution. I try to find and read your post, cause i don't subscibed to -arch. > > 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 Ye, as i thought. ;-) > 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 :-). The thing is that i do not implement Biba integrity model(BIM) right now. It is interesting integrity approach, but i'm concentrating on BLM. BIM and BLM rules are opposites. So BIM implementation would be an easy process, i suppose. 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.9912080757070.33108-100000>