From owner-freebsd-security Fri Mar 12 7: 1:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 4922C14C2D for ; Fri, 12 Mar 1999 07:01:09 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id JAA10732; Fri, 12 Mar 1999 09:56:24 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Fri, 12 Mar 1999 09:56:24 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Wes Peters Cc: Matthew Dillon , andrewr , Archie Cobbs , Andrew McNaughton , freebsd-security@FreeBSD.ORG Subject: Re: disapointing security architecture In-Reply-To: <36E927FC.ACDEEEC3@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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