--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-07-18 at 20:46 -0700, Casey Schaufler wrote:
> > --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 2007-07-17 at 19:59 -0700, Casey Schaufler wrote:
> > > > > > - Speaking of which, are you ok with your MAC model being
> overridden by
> > > > > > all uid 0 processes? Or do you plan to change securebits and use
> file
> > > > > > caps?
> > > >
> > > > I've been tracking the file caps closely. I like file capabilities,
> > > > but I have had success with uid 0 MAC systems as well. Long term, yes
> > > > I want file caps, but the uid 0 world is important, too.
> > >
> > > So uid == 0 is still all powerful with your module, right?
> > > No restrictions on any uid 0 process, not only for authenticated root
> > > shells but for any system process running with uid 0 or any setuid root
> > > program. They can override your MAC model at will, as well as
> > > indirectly subvert it via other capabilities. Whereas most (all?) other
> > > security modules to date allow you to restrict what capabilities can be
> > > exercised by a uid 0 process.
> >
> > Smack is intended to be a MAC module. I want to leave the privilege
> > model as an independent issue.
>
> It can be a separate mechanism, but there is a dependency there
> naturally (for protection of the MAC model).
To be sure. I have considered a variety of options. In the TCSEC B1
evaluated Trix there was a superuser, but even the superuser was
never allowed to violate the no-read-up rule. This lead to its own
set of unnatural application behaviors. The LSPP evaluated Trix
that came later is a pure capabilities system and used 5 MAC
capabilities, READ, WRITE, UPGRADE, DOWNGRADE, and RELABEL_OPEN.
I'm not going to claim we ever got everything right wrt file
capabilities, and that goes double for RELABEL_OPEN, which is the
primary basis for my stance on excesses of granularity.
> > > > > Other question there is if you aren't going to recheck on use, then
> what
> > > > > story do you tell wrt relabeling of files and/or tasks changing
> labels,
> > > > > given that you permit both to happen?
> > > >
> > > > It requires privilege. Really, that's the answer that's been used
> > > > on every B1/LSPP evaluation up until yours (Congratulations, BTW)
> > > > and an important aspect of the system is that labels don't change
> > > > very often, and only under controlled circumstances.
> > >
> > > The "labels don't change very often" bit is a good principle, albeit
> > > hard to achieve in an imperfect world.
> >
> > I think that the smack rules model will be helpful there, although
> > it will bring up issues of it's own.
>
> Hey, that's the selinux way of thinking - change the rules, not the
> label. The label describes the data (security properties thereof) and
> doesn't need to change.
There are differences (I say the label identifies the data, You say
the label describes the data) but it's not my fault if you got some
bits right.
> > > The "under controlled
> > > circumstances" seems hard to guarantee since to change task or file
> > > labels at all in your model, you are required to have complete
> > > MAC_OVERRIDE anyway, so there are no restrictions from a MAC point of
> > > view at all, and you have no other mechanism to protect and limit the
> > > process, other than DAC, which is fairly weak in its ability to provide
> > > such guarantees.
> >
> > That's an argument in favor of a fine grain privilege mechanism.
> > MAC_OVERRIDE is likely too coarse, where a capabilty for each
> > individual check is likely finer than is helpful.
> >
> > > That's one of the benefits of TE, being able to
> > > protect and limit MLS trusted subjects more effectively.
> >
> > If you like that level of granularity it's hard to argue
> > that TE is a poor choice.
>
> It does let you apply MAC overrides at the granularity not only of
> per-operation but per-object/label (i.e. trusted downgrader can
> downgrade these objects but not those objects, and can further only
> downgrade from X to Y), as well as help protect the integrity of the
> trusted subject. BTW, do you envision using this mechanism to express
> composite BLP+Biba simultaneously? If not, what's the plan for an
> integrity mechanism to complement BLP?
Trix supports (supported? When I checked in June my favorite
reference site had replaced the machines) BLP+Biba. Every user
had to specify both values at login, or use an alias. So the
choice was:
"msentsec,unclassified,student/mintbiba,usergrade"
or
"uofs", where that later was an alias for the former.
In the end everyone always defined an alias for every label that
every got used. I figured that I could chuck the alais translation
phase altogether by specifying the access relationships between
the alaises. Once you do that you can dump the notion that dominance
is the only interesting access relationship. Then you have Smack.
But to answer your question, a brief example of combined BLP+Biba:
SystemHigh is max(level), all categories
SystemLow is min(level), no categories
TS is level 7, no categories
S is level 5, no categories
S,Siz is level 5, category 38
S,McD is level 5, category 72
HighInt is min(grade), no divisions
LowInt is max(grade), all divisions
Select is grade 97
Choice is grade 86
Prime is grade 12
Chicken is grade 86, division 75
Smack BLA Biba
_ SystemLow HighInt Lowest Sensitivity, Highest Integrity
^ SystemHigh LowInt Highest Sensitivity, Lowest Integrity
Sizzler S,Siz Choice
MickyD S,McD Select
KFC TS Chicken
LeBucks S Prime
The Rules would be:
Sizzler LeBucks rx (S,Siz over S, Choice below Prime)
MickyD LeBucks rx (S,McD over S, Select below Prime)
KFC can't access anyone else because of the division in Chicken.
LeBucks can't access anyone else for both sensitivity and integrity.
It turns out that if you're making extensive use of both schemes
your available access list gets small really fast.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
