Date: Mon, 6 Dec 1999 18:41:13 -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.991206183755.12192D-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.9912060924240.60132-100000@ws-ilmar.ints.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Dec 1999, Ilmar S. Habibulin wrote:
> On Sun, 5 Dec 1999, Robert Watson wrote:
>
> > > Is -current posix target platform now?
> [...]
> > My guess is auditing won't be ready for 4.0, but hopefully will be for
> > whatever the next major 4.x release is. We might want to get MAC and
> > Capabilities in around then, although if you're reached final conclusions
> > on changes to the vnops and syscalls for capabilities we could try and get
> > them in now.
> What conclusion should i reach? I just need some space about 17 or let it
> be 24 bytes. I have all needed syscalls for CAP and MAC.
> I have freezed the development right now waiting for ACLs inclusion
> somewhere in the freebsd main source tree. All this posix stuff is very
> combined(?). MAC is nothing without AUDIT and so on.
> I would like to include all developed posix stuff in some development
> brunch, maybe -verrry-current ;-), and continue centralized
> development. The question is would freebsd project support posix 1e?
> Do the freebsd team need these extended security features in their OS?
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.
For reference, here's my current iteration of the ACL vnops interface,
with the modifications I discussed concerning stripping semantics from the
VFS interface to better support AFS and non-POSIX.1e ACL schemes (such as
the extensions you've mentioned):
#
#% getacl vp = = =
#
vop_getacl {
IN struct vnode *vp;
IN acl_type_t type;
OUT struct acl *aclp;
IN struct ucred *cred;
IN struct proc *p;
};
#
#% setacl vp L L L
#
vop_setacl {
IN struct vnode *vp;
IN acl_type_t type;
IN struct acl *aclp;
IN struct ucred *cred;
IN struct proc *p;
};
#
#% aclcheck vp = = =
#
vop_aclcheck {
IN struct vnode *vp;
IN acl_type_t type;
IN struct acl *aclp;
IN struct ucred *cred;
IN struct proc *p;
};
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?
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.991206183755.12192D-100000>