On Sun, 2007-07-29 at 08:48 -0700, Casey Schaufler wrote: > --- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > Quoting Andrew Morgan ([EMAIL PROTECTED]): > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Is this the sort of change that should be abstracted into the security > > > module API? > > > > > > To this point, everything about the fcap changes have been in headers > > > and within the security module code. > > > > Yes. I'd thought about adding a security_ops->inode_change() or > > somesuch hook, but there were two reasons I didn't. First, this > > should be done whether or not the capability module is loaded in > > this kernel. If we're testing a kernel with only the dummy > > module, we still want this to happen. Second, only the capability > > module needs this so far. If more modules end up needing this then > > we can make it more generic. But note that most security modules > > will likely label data the way selinux does, for classification for > > access control, rather than for granting privilege to unprivileged > > processes. > > Hum. I'm sure that my understanding is imperfect, but since the > SELinux policy will depend on the implementation of an application > (e.g. login, crontab) and the label on an application will depend > on the policy (it's not a name based scheme, after all) I should > think that overwriting a program binary on SELinux ought to result > in a change to the label on the binary, and that the new label ought > to be defined by the policy. That would argue strongly for an LSM > inode_change() hook that allows SELinux to set the label according > to the SELinux policy.
No, labels don't change when an existing file is overwritten; if the process was allowed to overwrite the file by policy, then the label is already appropriate. One would prevent untrusted entities from writing to the labels of trusted programs in the first place in one's policy. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
