Re: [RFC] [PATCH] Stacking through chaining (v3)

From: Stephen Smalley (sds@private)
Date: Tue Nov 30 2004 - 05:39:09 PST

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.

> 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

> That claim was inaccurate - the function was doing mostly the same thing
> as RETURN_ERROR_IF_ANY_ERROR, but with its own shortcircuit variable.
> Perhaps another variable should be added which lets stacker_capable act
> the way the original did, that is, authoritatively?  I don't want to make
> this too complicated...

I'd favor just being restrictive, and I'm not sure you need the separate
shortcircuit variable for capable.

Are there any issues with security modules internally calling the
top-level capable() function from a particular hook function when used
with the stacker?  There are examples of such usage in dummy,
capability, and SELinux.  Or should they always be calling their own
capable hook function (e.g. selinux_capable) instead when they want to
check a capability within a particular hook function?  The latter won't
set the PF_SUPERPRIV flag; not sure if that will be an issue for

Stephen Smalley <sds@private>
National Security Agency

This archive was generated by hypermail 2.1.3 : Tue Nov 30 2004 - 05:44:56 PST