Quoting Stephen Smalley (sds@private):
> On Thu, 2004-01-29 at 17:25, Serge E. Hallyn wrote:
> > Stacker now exports a sysfs file "next_secondary" which would be used as
> > follows:
> >
> > stacker compiled in
> > selinux compiled in
> > echo selinux > next_secondary
> > modprobe capability
> >
> > To get capability loaded as a secondary under selinux under stacker.
>
> In addition to the sysfs interface, how about a function provided by the
> stacker module that can be called by the SELinux module internally as
> part of its initialization to automatically set this "next_secondary"
> attribute after registering itself with the stacker. Then we could
> compile all three modules (stacker+selinux+capabilities) into the kernel
> and not require a userspace action on sysfs.
Good idea, I'll add that to the next version I send out.
> > In SELinux, then, SELinux still unregisters, but if a secondary is loaded
> > other than dummy, then SELinux manually loads that secondary whichever
> > way (ie 'register_security' or "mod_unreg_security") selinux itself had
> > registered.
> >
> > Does all that seem like a reasonable approach?
>
> Hmm...the problem is that this still can cause automatic escalation of a
> secondary module to primary module status without its awareness. Now,
> if using the stacker, then everything else is a "secondary", so that
> won't be a problem in practice. But if not using the stacker, you still
> have the same situation as you have today, i.e. SELinux runtime disable
> escalates capability from secondary to primary without any awareness by
> it. Only situation where that will matter is if capability is
> dynamically loaded, in which case it will be confused about how to
> unregister.
Hmm - which happens now as well, right?
Now... why are unregister_security and mod_reg_security different, other
than for symmetry? Why couldn't we just have
int unregister_security(const char *name, struct security_operations *ops)
{
if (ops == security_ops) {
security_ops = &dummy_security_ops;
return 0;
}
return security_ops->unregister_security(name, ops);
}
thanks,
-serge
PS - I'm looking into the capable() question...
This archive was generated by hypermail 2.1.3 : Tue Nov 30 2004 - 08:42:39 PST