--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

On Mon, 2007-08-13 at 15:51 +0100, David Howells wrote:

... 

quoted

Actually, to address Stephen Smalley's requirements also, how about making
things a bit more complex.  Have the following suite of functions:

 (1) int security_get_context(struct sec **_context);

	This allocates and gives the caller a blob that describes the current
	context of all the LSM module states attached to the current task and
	stores a pointer to it in *_context.

 (2) int security_push(struct sec *context, struct sec **_old_context)

	This causes all the LSM modules on the current task to switch to a new
	acting state, passing back the old state.  It does not change how
	other tasks do things to this one.

 (3) int security_pop(struct sec *context)

	This causes all the LSM modules on the current task to switch to a new
	acting state, deleting the old state.  It does not change how
	other tasks do things to this one.

 (4) int security_delete_context(struct sec *context)

	This deletes a context blob.

The context blob could then be structured very simply.  Give each loaded

LSM

quoted

module an integer index as it is registered.  Having a limit to the number

of

quoted

LSM modules would make things simpler.  The blob would then be an array of
void pointers, one per LSM module, indexed by the integer index for each

one.

quoted

It you don't have a limit on the number of LSM modules, you'd also need a
count of slots in the blob.

Any LSM module that wanted to implement the above three functions would

fill

quoted

in or otherwise use the slot that belongs to it.  Otherwise the slot would
just be left NULL.

For example:

	context --->+--------+                                    +---------+
	            | SLOT 0 |----------------------------------->| SELINUX |
	            +--------+                      +--------+    +---------+
	            | SLOT 1 |--------------------->| THINGY |
	            +--------+                      +--------+
	            | ...    |
	            +--------+         +-------+
	            | SLOT N |-------->| AUDIT |
	            +--------+         +-------+

For Stephen and NFS, he could then generate a context from NFS which nfsd
could then put in place.  Perhaps any unfilled slot would be ignored by the
LSM module to which it belonged.

Seems like over-design - we don't need to support LSM stacking, and we
don't need to support pushing/popping more than one level of context.

LSM stacking has always been contentious and I don't see
that it addresses the issue, which is changing the data used
by an LSM, not the LSM itself.

What was the objection again to the original interface, aside from
replacing "u32 secids" with "void* security blobs"?

The objection centers around exposing LSM specific data outside
the LSM, and it applies to either secids or blobs, really. If you
need this information outside the LSM odds are good that what you're
using it for is going to be LSM specific, and hence should be inside
the LSM. I admit to two gray areas, audit and system service tasks
such as the two cited here. I like simplicity and find the single
security_act_as() interface attractive for the latter case.


Casey Schaufler
casey@schaufler-ca.com