Re: MAC subsystem and ZFS?
- From: Robert Watson <rwatson@xxxxxxxxxxx>
- Date: Wed, 11 Feb 2009 17:52:14 +0000 (GMT)
On Mon, 9 Feb 2009, Borja Marcos wrote:
On Feb 7, 2009, at 11:21 PM, Robert Watson wrote:
I'm trying to upgrade the configuration of some web services, already using the MAC subsystem, to use ZFS instead of UFS, but I see that ZFS doesn't support MAC labels, even for a whole filesystem, which would be fine for me, I don't need multilabel support.
Any ideas? Have I missed anything?
Hmmm. Sounds like a bug -- all file systems should be able to operate in single-label mode, even if they don't support EAs and multilabel mode. Could you describe the symptoms you're experiencing in a bit more detail?
Indeed I can :) Sorry for the delay, a human nose-irritating virus, for which no known AV software exists, apart from patience, has kept me a bit parked this weekend :)
I can read the MAC label from a ZFS dataset, but cannot change it. Example follows:
Hi Borja:
This is the expected behavior for a single-label file system -- that is to say, a file system that doesn't support storing multiple labels. If EA support in ZFS is mature, it should be fairly straight forward to implement multi-label support. The following changes were made to UFS/UFS2 to support per-file label storage:
(1) Implement VOP_SETLABEL for the file system using vop_stdsetlabel_ea in the
any relevant vnode operation vectors:
#ifdef MAC
.vop_setlabel = vop_stdsetlabel_ea,
#endif
(2) Define a file system property, such as a superblock flack in UFS, that
will persisently store whether or not the file system is configured for
multilabel operation (so that singlelabel operation can still be
supported):
#define FS_MULTILABEL 0x20 /* file system is MAC multi-label */
(3) Trigger setting of MNT_MULTILABEL based on that flag being set:
if ((fs->fs_flags & FS_MULTILABEL) != 0) {
#ifdef MAC
MNT_ILOCK(mp);
mp->mnt_flag |= MNT_MULTILABEL;
MNT_IUNLOCK(mp);
#else
printf("WARNING: %s: multilabel flag on fs but no MAC support\n",
mp->mnt_stat.f_mntonname);
#endif
}
(4) When vnodes become associated with particular file system objects, ensure
that the vnode label has been properly set up from the EA data, such as in
this code from ffs_vget:
#ifdef MAC
if ((mp->mnt_flag & MNT_MULTILABEL) && ip->i_mode) {
/*
* If this vnode is already allocated, and we're running
* multi-label, attempt to perform a label association
* from the extended attributes on the inode.
*/
error = mac_associate_vnode_extattr(mp, vp);
if (error) {
/* ufs_inactive will release ip->i_devvp ref. */
vput(vp);
*vpp = NULL;
return (error);
}
}
#endif
The utility routine mac_associate_vnode_extattr() should be called with
the vnode lock held, and before any I/O (etc) can take place on the object
so that appropriate security information is guaranteed to be available.
(5) When a new object is allocated and a vnode is associated with it, ensure
that a new label is created for the object and both set in the EA and
loaded into the vnode label:
#ifdef MAC
if (dvp->v_mount->mnt_flag & MNT_MULTILABEL) {
error = mac_create_vnode_extattr(cnp->cn_cred, dvp->v_mount,
dvp, tvp, cnp);
if (error)
goto bad;
}
#endif
Again, we have a utility routine, mac_create_vnode_extattr(), that does
all the work, and is passed the parent directory object, mountpoint,
creator credential, etc so that the new label can be derived and written
to disk. This needs to happen before any I/O is possible on the vnode so
the security information is available for access control. In UFS, this
happens in two places -- general file create, and separately for directory
create.
(6) Cause VOP_PATHCONF to return an appropriate flag so applications know that
per-file labeling is available:
case _PC_MAC_PRESENT:
#ifdef MAC
if (ap->a_vp->v_mount->mnt_flag & MNT_MULTILABEL)
*ap->a_retval = 1;
else
*ap->a_retval = 0;
#else
*ap->a_retval = 0;
#endif
(7) There may be some places where you need to explicitly disable MAC
checking, such as internal calls to vn_rdwr() on directories, or name
lookup, where there isn't a convenient privileged credential but the work
is arguably on behalf of the file system. IO_NOMACCHECK can be used for
vn_rdwr and NOMACCHECK for namei.
I'm happy to help review patches and discuss this further; the hooks/utility routines were very much designed with UFS in mind, although intended to be generic enough to support other file systems, and we may want to revise them as we gain experience.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
# zfs create pool/test
(indeed I can read the default label applied when creating it)
# getfmac pool/test
pool/test: biba/high,mls/low
(but I cannot change it)
# setfmac biba/equal,mls/equal /pool/test
setfmac: labeling not supported in /pool/test
(just in case it's a confusion because of being under "/pool", I try changing the mountpoint, still no success)
# mkdir /testing
# zfs set mountpoint=/testing pool/test
# setfmac biba/equal,mls/equal /testing
setfmac: labeling not supported in /testing
This is a 7.1.RELEASE-p2 system.
Thank you very much,
Borja.
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: MAC subsystem and ZFS?
- From: Borja Marcos
- Re: MAC subsystem and ZFS?
- From: Borja Marcos
- Re: MAC subsystem and ZFS?
- References:
- MAC subsystem and ZFS?
- From: Borja Marcos
- Re: MAC subsystem and ZFS?
- From: Robert Watson
- Re: MAC subsystem and ZFS?
- From: Borja Marcos
- MAC subsystem and ZFS?
- Prev by Date: Re: OPIE considered insecure
- Next by Date: Re: OPIE considered insecure
- Previous by thread: Re: MAC subsystem and ZFS?
- Next by thread: Re: MAC subsystem and ZFS?
- Index(es):
Relevant Pages
|
