Re: [RFC][PATCH 1/3] EVM

From: Stephen Smalley (sds@private)
Date: Fri Nov 18 2005 - 04:57:12 PST


On Thu, 2005-11-17 at 17:29 -0500, David Safford wrote:
> We did not understand that d_instantiate is the preferred approach, 
> partially because it is not well documented in security.h. If this
> is the better method, it would certainly seem possible to move to this 
> hook.

Reading security.h is a poor substitute for looking at a real working
implementation of a LSM that is already upstream.  I'd certainly
encourage adding inline documentation to security.h for the
d_instantiate hook (and others that are presently undocumented), but in
the end, the best source of information about how to write a LSM is
going to be examining the code of an existing upstream LSM, not the
comments in that header.

The security_d_instantiate hook was introduced precisely for the purpose
of inode security initialization, as discussed in the
linux-security-module and linux-kernel mailing list archives.
Naturally, you want to use security_inode_init_security to set up newly
created inodes (and if it lacks something, you want to adapt it, not
re-introduce post_create hooks).
 
> After conversion of the configuration code to securityfs,
> we allow only one initial configuration (which we do in 
> the initrd, when there is only the one init process), and
> then we remove the securityfs config file.

That seems fairly limiting - why not just provide locking?

-- 
Stephen Smalley
National Security Agency



This archive was generated by hypermail 2.1.3 : Fri Nov 18 2005 - 04:51:05 PST