Date: Fri, 12 Mar 1999 09:56:24 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Wes Peters <wes@softweyr.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, andrewr <andrewr@slack.net>, Archie Cobbs <archie@whistle.com>, Andrew McNaughton <andrew@squiz.co.nz>, freebsd-security@FreeBSD.ORG Subject: Re: disapointing security architecture Message-ID: <Pine.BSF.3.96.990312094955.6494T-100000@fledge.watson.org> In-Reply-To: <36E927FC.ACDEEEC3@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Mar 1999, Wes Peters wrote: > Robert Watson wrote: > > > > C2 certification is presumably also an expensive process; if someone wants > > to find a sponsor, we could almost certainly achieve C2 compliance with a > > little restriction of the base system and appropriate POSIX.1e options. > > Having a nice big "C2-Compliant!" stamp on the 4.0 CD would blow the > > competition out of the water (so to speak) and certainly be excellent PR. > > You cannot certify a piece of software, only a computing system. What > would be certified is a particular configuration of FreeBSD X.Y, > configured precisely so, on exactly THIS hardware. ANY deviation from > the specified hardware, even more or less RAM, invalidates the > certfication (unless various RAM configurations are part of the > certified system, of course). Your best bet for a sponsor may be a > computer vendor. True; on ther other hand, it would be *quite* worthy of a big press release. :-) Maybe Whistle wants their InterJet to have a C2 certification? :-) Leaving aside the issue of certification, however, having the features required for certification is certainly a good idea. Recently I've been thinking about how to implement Capabilities and ACLs, now that Auditing is essentially complete. I dug up a masters thesis from somewhere describing implementing ACLfs using file system layers. My thought was instead to implement it using multiple forks of a file in a single file system, as the layering structure is fairly toasted, and I'd rather not deal with it. The ACLs themselves aren't that complex, as they are really just a superset of the UNIX permissions in POSIX.1e. However, adding support to the FS seems more challenging and I'd welcome thoughts on the best way to do it. The Solaris folk now appear to have ACL support in the base OS install + FS. Where did they find the space to store the ACLs? Adding any more serious data to the inode results in reduced performance as you chew through direct block pointers. Adding a new block that stores just ACL data sounds feasible, but removes the simplicity of the whole thing and would require rewriting bunches of stuff (fsck, etc). Adding file system forks (file:data, file:acl, NT-style) sounds interesting, but again is a fairly large amount of work. I suppose one could use layering to do this--reserve the : character (or something else) and have a file system layer merge the various components stored in seperate files into a single uber-file with various forks accessible via the name space, each with their own permissions and ownership. I.e., only the kernel could modify ACLs via the ACL API. Capabilities are essentially a set of flags in POSIX.1e so presumably a reserved int32 or int64 exists in there somewhere. Discussion of the flags is probably best handled on the posix1e mailing list as that's a portability issue. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ 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.990312094955.6494T-100000>