Low Watermark MAC (LOMAC) implementation for Linux

[Ilmar S. Habibulin]

On Thu, 14 Oct 1999, Robert Watson wrote:

> 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.

struct dinode {
	u_int16_t	di_mode;	/*   0: IFMT, permissions; see below. */
	int16_t		di_nlink;	/*   2: File link count. */
	union {
		u_int16_t oldids[2];	/*   4: Ffs: old user and group ids. */
		int32_t	  inumber;	/*   4: Lfs: inode number. */
	} di_u;
	u_int64_t	di_size;	/*   8: File byte count. */
	int32_t		di_atime;	/*  16: Last access time. */
	int32_t		di_atimensec;	/*  20: Last access time. */
	int32_t		di_mtime;	/*  24: Last modified time. */
	int32_t		di_mtimensec;	/*  28: Last modified time. */
	int32_t		di_ctime;	/*  32: Last inode change time. */
	int32_t		di_ctimensec;	/*  36: Last inode change time. */
	ufs_daddr_t	di_db[NDADDR];	/*  40: Direct disk blocks. */
	ufs_daddr_t	di_ib[NIADDR];	/*  88: Indirect disk blocks. */
	u_int32_t	di_flags;	/* 100: Status flags (chflags). */
	int32_t		di_blocks;	/* 104: Blocks actually held. */
	int32_t		di_gen;		/* 108: Generation number. */
	u_int32_t	di_uid;		/* 112: File owner. */
	u_int32_t	di_gid;		/* 116: File group. */
	int32_t		di_spare[2];	/* 120: Reserved; currently unused */
	^^^^^^^^^^^^^^^^^^^^^^^^^^^
};
Lets use these free space to store pointers to disk blocks containg
extended attributes. di_spare field is bzero'ed while allocation of the
inode, so null pointer should point to the absense of the extended
attributes. And we can dynamically allocate blocks without
upgrading/reconstructing fs.

> 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
I suppose to use set_ext_attr/get_ext_attr interface.

> 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,..
It's just another data type.

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message