On Tue, 2005-11-15 at 09:08 -0500, David Safford wrote: > Patch 2/3 - SLIM (Simple Linux Integrity Model) > > SLIM is an LSM kernel module which performs a simple low water-mark > form of integrity mandatory access control. In this model, files are > labeled with the security.slim.level extended attribute, which, along > with the hash of the file’s data, is authenticated by EVM. Values for > the integrity level are SYSTEM, USER, and UNTRUSTED. Obvious question: what guarantees that slim and evm have a consistent view of the slim attributes, i.e. since slim and evm appear to independently perform getxattr calls, what prevents the attribute value from changing between those calls? Another obvious question: since slim directly makes calls to evm and look at its data structures, and is placed under evm in the tree, what does any of this have to do with the stacker? You could just as easily have the slim hooks call evm in all cases where needed, and likewise couple other LSMs with evm as desired through direct calls rather than using the stacker. The composition isn't truly transparent in any event. > SLIM also performs a corresponding high water-mark privacy model, with > levels PUBLIC, USER, USER-SENSITIVE and SYSTEM-SENSITIVE, although these > labels are not yet well tested. Then they should be omitted. > Executable files can be designated as integrity guard programs with > additional labels for the lower and upper watermarks allowed. > The value of a security.slim.level attribute is ascii, in the form: > > Integrity_Level Privacy_Level [Guard_Low_level Guard_High_Level][UNLIMITED] So they can contain whitespace and have no terminator? Unpleasant for parsing. If you were to e.g. extend ps to display your labels among other fields, what would indicate the end of your labels? > Files are initially labeled during installation/update with a modified > version of rpm, which uses the /etc/slim.conf configuration file to > determine the appropriate level for a file. For labeling an existing > filesystem, the tpm-3.0.3 package includes tc_label, a labeling > application, which can clear, initialize from the rpm database, > initialize from /etc/slim.conf, and manually set individual files, > files in one or more rpm packages, or directories recursively. "Recursively" sets off a red flag. If a file is visible under multiple paths (hard links, bind mounts), does its label depend on the path by which it is accessed? If a file is renamed to a different location, does it automatically pick up the new label if inheriting? Also, on the implementation side, I see that slm_getr_xattr among other functions are walking up d_parent without any kind of locking. See dget_parent() in include/linux/dcache.h. As with evm, locking seems to be missing pervasively, allowing various races on inode security setup, task security setup, etc. post_create and friends are fundamentally racy, as previously noted. Another thread may already have found your inode in the dcache and be using it at this point. It doesn't help to perform locking in the hook function; the inode is visible to other threads _before_ you ever enter the hook. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Wed Nov 16 2005 - 12:53:48 PST