On Mon, 2005-10-17 at 15:08 -0400, David Safford wrote: > This is a request for comments on the attached patches which implement > two LSM modules, EVM and SLIM. These patches are also available, along > with sources for associated user space programs, and technical papers, > at http://www.research.ibm.com/gsal/tcpa in the tpm-3.0.2 package. > > EVM (Extended Verification Module) is similar to digsig, in that it > provides access control based on file integrity, but it provides this > protection for all files (not just executables) through a general > mechanism of authenticated extended attributes, based on keys > protected by "TPM trusted boot". EVM is configurable to protect any > extended attributes, including those for SLIM and selinux. In addition, > when EVM is LSM stacked, the data and metadata integrity information can > be passed to subsequent modules for further access control enforcement, > such as demoting the integrity level of any process allowed to access > the questionable file (i.e. sandboxing), and SLIM demonstrates this > stacking. > > SLIM provides a simple integrity mandatory access control, similar > to LOMAC, but using EVM information to aid decisions, and to ensure > the integrity of guard processes. The former IMA (Integrity Measurement > Architecture) is included as a configurable part of SLIM. While IMA is > not an access control component, if integrity attestation is desired, it > is most efficiently implemented here, as EVM has already measured all > files, and SLIM knows which ones are integrity sensitive, and which > should therefore be added to the TPM registers. Since you mentioned digsig, how does evm compare with it aside from what you mention above? digsig seemed to go to great lengths to try to prevent modification of the executable after validation, and made use of the file_mmap hook for the actual checking, IIRC. What is the plan for initialization and maintenance of these new extended attributes? How do you intend to integrate with package managers? Red flag: I see path_lookup(bprm->filename...) calls in your security modules (both of them). Tell me what prevents that lookup from returning a different result than the kernel received upon the open_exec, thereby opening a trivial race condition/TOCTTOU vulnerability in your security module? Why aren't you just using bprm->file? More generally, tell us about how you are preventing tampering after validation and your locking scheme (which seems to be missing). > The tcfl-lsm.patch reintroduces the inode_post_create and > inode_post_mkdir hooks. EVM needs a way to HMAC newly created > extended attributes after they have been written, which is > not possible through the inode_init_security hook. We would > certainly like to see these hooks reintroduced to LSM, if EVM > is eventually accepted. post_create-style hooks in the VFS are fundamentally racy, as the inode is already accessible via the dcache to other threads at that point. Are you sure you want them? What are you doing to address the potential race? -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Tue Oct 18 2005 - 06:04:51 PDT