Re: MAC and DAC and the combination

["YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>]

Thanks, Michael and Nir

It is laughable, but I was serious and tried to find out an instance that
might be implied by the MAC&DAC "combination".
The sample presented by Nir is simple for the intent.
It's clear to me.

Thanks,
 Hirofumi Yokota

----- Original Message ----- 
From: "Nir Naaman" <nir.naaman@metasec.com>
To: "Multiple recipients of list" <cc-cmt@nist.gov>
Sent: Thursday, February 08, 2007 9:31 PM
Subject: RE: MAC and DAC and the combination


>
> Yokota,
> See also CC Part 2 appendix F for these acronyms:
> MAC = Mandatory Access Control
> DAC = Discretionary Access Control
>
> NIAP Interpretation I-0451 provides some additional guidance on how these
> terms were transformed going over from the TCSEC to the CC.
>
> PD-0011 has been superseded by I-0363 and later by I-0420. What the text
is
> saying is that while ACC/ACF and IFC/IFF govern how controlled subjects
> interact with controlled objects and information using controlled
> operations, and FMT_MSA.1 and FMT_MSA.3 restrict the modification of those
> attributes to specified roles, there is no SFR that allows you to specify
> rules for security attribute initial values and allowed transitions.
>
> For example, think about the following rule: a labeled object can never be
> downgraded to a lower security label (a high watermark SFP). It's somewhat
> awkward to express that with the existing SFRs.
>
> Of course, FMT_MSA.2 is a magic SFR that fixes this and almost any other
> problem. :)
> It ensures that only "secure" values are accepted for security attributes.
> I'm not sure anybody's ever figured out what this means, but that doesn't
> mean it's not widely used.
>
> As you can see, the FDP_ATR family was *not* added to the FDP class. This
> issue is one of many that was intended to be fixed by CCv3.0 (see FDP_ISA
> and FDP_MSA), but was dropped in CCv3.1.
>
> This is not to say that ATR.1 is not a good idea, but I don't know of any
PP
> that includes it, and running a quick search, found only one ST (one of
> mine, actually) that actually used this SFR component.
>
> For a relatively recent ST that defines MAC and DAC requirements, see the
> BAE Systems Information Technology, LLC Security Target Version 1.11 for
> XS-400, Version 6. As you may see, the attribute value transition
> requirements were apparently established using a creative application of
the
> 3 and .4 elements of FDP_IFF.
>
> Hope this helps,
>    Nir
>
>
> > -----Original Message-----
> > From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of
> > YOKOTA HIROFUMI
> > Sent: Thursday, February 08, 2007 3:51 AM
> > To: Multiple recipients of list
> > Subject: MAC and DAC and the combination
> >
> >
> >
> > Hi,
> >
> > What is MAC? and What is DAC?
> > I suppose, new generations and IT security beginners are
> > having fewer chances to learn those terms in-depth.
> > And, I would say, it is very hard to read those terms,
> > especially when they are used in combination as follows.
> >
> > --------------------------
> > PD-011 Attribute Inheritance/Modification Rules Need To Be
> > Included In Policy The "Issue" says:
> > For example, one cannot use FMT_MSA to specify a rule that a
> > Mandatory Access Control SFP must be satisfied in order to
> > set security attributes controlled under a Discretionary
> > Access Control policy. So how can this be done?
> > --------------------------
> >
> > Before to know how this can be done using the cc
> > specifications, we need to know the meaning of this MAC/DAC
> > combination.
> > Namely, the meaning of the rule: that a Mandatory Access
> > Control SFP must be satisfied in order to set security
> > attributes controlled under a Discretionary Access Control policy.
> >
> > Could such a rule and a situation flush into your imagination?
> > Could someone illustrate this, using the CC terms: i.e.,
> > subject, object, information flow, rules, access control
> > list, attributes, pass/deny, etc ?
> >
> > Thanks advanced for your help.
> >
> > Best regards,
> >  Hirofumi Yokota
> >
> >
>
>