interesting comments.. I fooled around with it and and it seems like there are these "exempt" processes? That is, if you hack one of those "exempt" processes (services) you can compromise the whole system, right.? So, what's the point? Isn't the net result still an insecure system that's more difficult to maintain? That's more difficult to deploy? And stacker is now being "re-patched"?... ok.. is there going to be a fork in the stacker tree? I would love to have a secure system that is easy to maintain. What benefit is gained from deploying this when it appears to be fundamentally flawed? ( race conditons.. exceptions, etc ) Bob ----- Original Message ----- From: "Stephen Smalley" <sds@private> To: "David Safford" <safford@private> Cc: <linux-security-module@private> Sent: Tuesday, October 18, 2005 9:00 AM Subject: Re: [RFC][PATCH] EVM and SLIM LSM modules > 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 __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
This archive was generated by hypermail 2.1.3 : Tue Oct 18 2005 - 12:39:11 PDT