--- "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. Casey Schaufler [EMAIL PROTECTED] - 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
