Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Oct 1997 20:44:45 -0500 (CDT)
From:      Jim Bryant <jbryant@unix.tfs.net>
To:        tlambert@primenet.com (Terry Lambert)
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: C2 Trusted FreeBSD?
Message-ID:  <199710140144.UAA02191@argus.tfs.net>
In-Reply-To: <199710140038.RAA16216@usr07.primenet.com> from Terry Lambert at "Oct 14, 97 00:38:20 am"

next in thread | previous in thread | raw e-mail | index | archive | help
In reply:
> > certification or not, i personally think that acl-based object access
> > is something that would work in FreeBSD's favor, especially given the
> > now infamous unix-slam from nt fans on the subject...
> 
> ACL code is trivial, once stacked FS modules works correctly.  The quota

agreed.  additional filesystem flags.

i'm thinking that existing apps COULD be integrated seamlessly.  an IP
approach could be used with a twist such that null flags would
indicate unclass, and thus either no acl action would be taken; or a db
lookup made, and if no db entries, no acl action made, etc...

i prefer the latter method, as it would allow acl to be added to even
pre-acl objects.

the IP approach to filesystem flags would only require an additional
11 bytes per entry if used verbatim from IP, and might ease a
transition to a compliant TCP/IP stack, could also be used to
segregate the acls themselves [secret flag indicates that acl is
located on secret media, not confidential media]...

the key to any such DESIGN would require the transparent inclusion
of non-compliant apps as unclass, non-acl items.  of course the
capability would exist to reclassify and add acl access transparent to
the app.

> code ought to be moved to a stacking layer, as well.  Unfortunately, the
> FS framework has problems right now, and it's not terribly clear if they
> will ever be solved without someone on the core team doing the actual
> work, since the changes required are so large that only a core team member
> could do them in the face of the fear that much change generates.

yes the changes would be large, and of course would require core team
coordination.

jim
-- 
All opinions expressed are mine, if you    |  "I will not be pushed, stamped,
think otherwise, then go jump into turbid  |  briefed, debriefed, indexed, or
radioactive waters and yell WAHOO !!!      |  numbered!" - #1, "The Prisoner"
------------------------------------------------------------------------------
Inet: jbryant@tfs.net    AX.25: kc5vdj@wv0t.#neks.ks.usa.noam     grid: EM28pw
voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM.   http://www.tfs.net/~jbryant
------------------------------------------------------------------------------
HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710140144.UAA02191>