Chris Wright <chrisw@private> wrote on 06/15/2005 05:53:01 PM: > * serue@private (serue@private) wrote: > > Quoting Chris Wright (chrisw@private): > > > The primary purpose of the hooks is access control. Some of them, of > > > course, are helpers to keep labels coherent. IIRC, James objected > > > because the measurement data was simply collected from these hooks. > > > > Ok, so to be clear, any module which does not directly impose some form > > of access control is not eligible for an LSM? > > That's exactly the intention, yes. Chris, 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. 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? 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. These properties neither justify IMA to be excluded as LSM, nor force IMA to be an LSM. > thanks, > -chris Thanks Reiner
This archive was generated by hypermail 2.1.3 : Wed Jun 15 2005 - 15:53:19 PDT