Date: Thu, 14 Oct 1999 15:29:16 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: freebsd-arch@freebsd.org Subject: Re: Low Watermark MAC (LOMAC) implementation for Linux (fwd) Message-ID: <Pine.BSF.3.96.991014152141.31035H-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
One of the topics that comes up quite a bit on the posix1e mailing list is how to fit security extension data into the file system of operating systems needing security extensions. Right now, we're discussing MAC labels but ACLs are also relevant. In BSD-land, we usually say things like "use a filesystem layer" in response to the suggestion that additional metadata should be added. However, I'm concerned about the transactional properties of security attributes--it's important that a coerced system failure (kernel panic, power outage, whatever) not leave a file unprotected because the inode was updated but the ACL was left behind, or the like. Currently, permissions are in the inode, so that works ok, but if the ACLs were pulled from another layer of the FS, that wouldn't be the case. XFS appears to support generic attribute extensions, although I don't know anything about it and am trying to get documents to find out more about it. NT supports named file forks, etc. The big sticking point for the Linux ACL and Capability people has been where to put their data. The other question is how aware should the VFS/vnode calls be of ACLs and security labels. There's a decent argument that ACLs are like other attributes (file permissions, etc) and it is ok to expose them at all levels -- add a Posix-style ACL descriptor struct, have it passed around in the same way as the other attributes via get/setacl vnode calls. Alternatively, it could be integrated into the attribut structure (not good because, for example, the IRIX ACL struct is 308 bytes, dramatically increasing the size of an inode if it ends up there, and also breaking a binary interface to both the kernel and the fs). Since the fs is reponsible for enforcing ACLs, it wouldn't require too may sweeping changes--most file systems could leave it unimplemented, but fs's that support ACLs (such as NTfs, Coda, AFS, etc) might be able to expose some of that via the Posix interface. Would the general FreeBSD community be opposed to addition of two new vnode calls of this type, and the appropriate structs to describe their interface, as well as syscalls to match? This might facilitate the development of ACL support, and not prohibit the layer implementation, as it could still be handled by an ACLfs layer that spoke ACLs. Anyhow, opinions and comments would be greatly appreciated. Cross-platform comments on implementation could be CC'd to posix1e@cyrus.watson.org, but FreeBSD-specific stuff should probably stay on -arch or elsewhere. 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 ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 15:18:49 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> Reply-To: Robert Watson <robert+sec@cyrus.watson.org> To: "Ilmar S. Habibulin" <ilmar@ints.ru> Cc: Casey Schaufler <casey@sgi.com>, posix1e@cyrus.watson.org Subject: Re: Low Watermark MAC (LOMAC) implementation for Linux On Thu, 14 Oct 1999, Ilmar S. Habibulin wrote: > On Thu, 14 Oct 1999, Casey Schaufler wrote: > > > We've got a little bit of a dilemma here. On one hand, we'd > > love to say that the extended attribuites of XFS are the way > > to go. On the other hand, we recognize that XFS may never be the > > default file system for Linux. For file systems other than XFS > > another mechanism may be required. > Can you point some url, describing this fs or somehow describe it by > yourself? > > > So, until XFS is available, a file system independent scheme may > > be the most appropriate. I have attached (PostScript - sorry) a > > description of what we did before we had XFS. It's not actually > As i understand it is something like quotas in ffs, am i right? This > approach was proposed by Robert. I don't understand why my thoughts were > not supported? Is an idea of some improvements in ffs so terrible? ;-) Well, the idea of updating FFS I think is a good one--perhaps to have some generic attributes support of the type XFS appears to have. Please forgive my ignorance as to the design of XFS--I've mostly lived in Linux-, Solaris-, and BSD-land in the past few years, so am not familiar with it's particular quirks/features. Anyone have a good reference for the design/implementation of XFS online, or in a journal or the like? I'm also interested in how the Solaris folk fit ACLs (and presumably other things) into their FFS. One of the things that I think is important is to give ACL/other security-relevant tags the same atomic update properties that attribute information in traditional inode structures has--i.e., in the event of an untimely power loss, it's not possible to end up with the inode but not the associated ACL or MAC data. Fitting the data into the inode directly might be one way to do this, but it's probably desirable to have a general extension mechanism (such as XFS-style attributes, possibly?) so we don't have to keep modifying the file system. This can result in painful upgrade procedures, divergences in mainstream and secure code, etc. I'm out of town this weekend, but I think the next step in BSD support for ACLs/MAC support in the FS is to add support in the VFS/vnode layer for requesting and modifying these attributes. How that interface looks depends a bit on whether we have a general-purpose extension mechanism or not. Given the proliferation of various file systems at this point, it might make sense to add kernel-level VFS interfaces such as getacl, setacl, getmaclabel, setmaclabel, and let the file system decide how to store this data. This might allow the hiding of AFS or Coda ACLs behind a POSIX.1e ACL interface, which would probably be quite desirable, if feasible. There are downsides to this, of course, including that the vnode/vfs layer is now aware of a particular kind of ACL interface or MAC interface--of course, it already knows about permissions, and in a sense it's just passing back and forth binary blobs most of the time for ACLs as the FS layer itself enforces the limits, I believe. For the MAC data, however, that's a different question,.. 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@cyrus.watson.org with "unsubscribe posix1e" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" 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.991014152141.31035H-100000>