Re: [PATCH] 3 of 5 IMA: LSM-based measurement code

[Chris Wright]

* Reiner Sailer (sailer@xxxxxxxxxx) wrote:
> Access control is a very broad term. Before I go into details, I would 
> like to make clear that I do not have a preference for or against LSM. We 
> are working hard to make the functionality available and it does not 
> matter to the user where IMA will be located. The true potential of 
> Trusted Computing will only show with experimenting going on outside 
> the research labs. IMA can help by being one modest building block 
> for experiments only if it is broadly available.

Yeah, understood.

> Regarding the access control discussion, one can map (almost) anything 
> onto access control. There are (many) people that teach today that the 
> whole security issue is about access control. The question is: 
> controlling access of whom to what?

OK, let's look at it another way.  Say your access control model used
kernel profiling data as part of policy.  It still makes sense to let
oprofile do that collection, and the LSM is just a consumer of that
data when it makes an acces control decision.  Perhaps a klunky analogy,
but do you see the idea?

> IMA does control access by forcing measurements on executables
> before they are loaded. Access control is more than saying yes or no at 
> some point on the code path. IMA enables remote parties to figure out 
> whether a system has some (usage dependent) properties. This can serve as 
> the basis for controlling such systems' access to resources. IMA supplies 
> input into a remote Access Control Decision Function.

Right, the measurement data collection stand alone, which no access
control decisions in sight (talking about the IMA LSM now), is what
tipped the scale.

thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/