Re: Authoritative Hooks

caseyat_private

Stephen Smalley wrote:
> 
> On Mon, 12 Nov 2001, Casey Schaufler wrote:
> 
> > One more thing ...
> >
> > I wrote:
> >
> > >     if (!(uid-checks-out-okay) && !capable(CAP_XYZ))
> >
> > should be changed to:
> >
> >       if (!capable(CAP_XYZ) && !(uid-checks-out-okay))
> 
> You're asking for a change to the base kernel logic, not just a change
> to LSM.

Yes, but it's a change that should be made if the official
LSM reccomendation on how to do ACLs is to use C+R.

> And the base kernel seems to prefer only calling capable if the
> capability is truly needed, after a failure of the base DAC logic.

That is certainly the Right Thing to do if you care about Audit!

I had also considered proposing:

	if ((lsm_model() == LSM_RESTRICTIVE) &&
	    !(uid-checks-out-okay) &&
            !capable(CAP_XYZ))

which is just as intrusive but much clearer in intent.

> > if C+R is going to be the Official way to use LSM.
> > Otherwise, the architecture is going to advocate
> > (require?) that code with potential side-effects
> > get executed in cases where it is at best unnecessary
> > and in some cases (side effects) may cause the system
> > to break.
> 
> I'm not sure what you mean by "the official way to use LSM."  I have
> simply argued that POSIX ACLs can be implemented via the current LSM
> without needing authoritative hooks, so your earlier example of POSIX
> ACLs isn't motivating for authoritative hooks.

It is still motivating. It fails to demonstrate that C+R
can't do the trick, but succeeds in demonstrating that it
is a trick. 

> That isn't to say that
> there aren't motivating examples for authoritative hooks, just that POSIX
> ACLs isn't one of them.

OKay. I disagree, but we knew that already.

> Are there specific example of the side effects that you mention?  As I
> said above, the ordering of the DAC logic and the capable call is part of
> the base kernel, so I don't see what your point is here.

We did cover this earlier in the case of near line storage systems.

The crux of my point, and I'm sorry that we get bogged down in
examples, is one of architecture. If we say that restrictive hooks
are good enough because one can resort to C+R, then we also need
to say that C+R is good enough *in the general case*. For this
to be true there needs to be a architectureal relationship between
capable() calls and LSM hooks. In particular, it must be the case
that each capable() must be followed by an LSM hook. If this is
not true, it is possible that there will be cases where a
change to the behavior of capable() for one set of objects will
result in changed behavior in another set of objects and there
will be nothing that the developer can do within LSM to prevent
the problem. One could argue that these should be addressed on
a case-by-case basis, with LSM being expanded to address each
of these as required, and I fully expect one of you to do so.
I am concerned that those for whom security isn't a primary focus
(the blighters!) will not maintain this architectural principle
and will sprinkle code with capable() calls but not LSM hooks.

How about this: Would someone who favors restrictive hooks
write down the architectureal overview of what's being proposed?
It might help me get over my misguided worldview and would at
very least make a good start for a Conference Paper.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
caseyat_private				voice: 650.933.1634
casey_pat_private			Pager: 888.220.0607

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module