PERFORCE change 20657 for review

Brian F. Feldman green at freebsd.org
Mon Nov 4 21:07:59 GMT 2002


Robert Watson <rwatson at freebsd.org> wrote:
> On Mon, 4 Nov 2002, Brian F. Feldman wrote:
> 
> > Brian Feldman <green at FreeBSD.org> wrote:
> > > http://perforce.freebsd.org/chv.cgi?CH=20657
> > > 
> > > Change 20657 by green at green_laptop_2 on 2002/11/04 11:34:53
> > > 
> > > 	Be resilient to relabel operations on mac_lomac objects by
> > > 	always blanking the destination and copying the old label,
> > > 	but only if the new label "appears" internalized.
> > 
> > BTW, this really does apply to all policies, and needs to be documented
> > as such.  Biba/MLS got it "not totally wrong" because they don't bzero
> > the label they're overwriting, so in the case where there's nothing to
> > copy they just overwrite nothing on the target label. 
> 
> I guess I would interpret the Biba and MLS behavior a little differently: 
> Biba and MLS labels optionally have 0, 1, or 2 of their components defined
> (single, range).  Biba and MLS will avoid updating any component that
> hasn't had an update requested, and the conditional copy implements this
> behavior.  I.e., if you don't request single be updated, it won't replace
> the single component.  That representation does coincide with the
> initialized and not internalized/created definition intentionally -- are
> you suggesting that we just need to add a comment indicating as much, or
> that we need to change behavior?

It's not immediately obvious, nor is it even obvious upon deep inspection, 
what the right behavior is supposed to be without the correct documentation 
there.  I don't think making things like this completely implicit is helpful 
in the understanding of these policies, so some sort of documentation in the 
code really needs to occur, in my opinion.  I think adding a specific 
"relabel" helper function which documents the assumption being operated upon 
is the best way to go.  Then again, I'd prefer to not have an initialized, 
non-NULL label passed into unsuspecting policies, but I know that's not 
something you want to try to do now :)

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org  <> bfeldman at tislabs.com      \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message



More information about the trustedbsd-cvs mailing list