--- David Howells <dhowells@redhat.com> wrote:

Stephen Smalley [off-list ref] wrote:

quoted

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.

It will, at some point hopefully, be possible for someone to try, say, NFS
exporting a cached ISO9660 mount (CDROM) - in which case, we'd should allow
for two levels of stack.  If we can pass the displaced context to the caller
to restore later then that allows for more or less unlimited depth.

It occurs to me that the following is almost good enough, but not quite:

  (1) int security_get_context(void **_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.

Is this intended to be anything more than a copy of current->security?

  (2) int security_push(void *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.

I assume that you're talking about the LSM specific data changing,
not the LSM itself.

If you change the task->security information you are definitly going
to change what other tasks can do to the calling task. This is part of
the dark side of label swapping. This is what I was trying to suggest
when I said that if you're going to switch labels you switch to a
system-daemon label, do your work, then change the file label explicitly.
Stephen may have a trick up his sleeve for SELinux, but I don't
expect it to be pleasent.  

  (3) int security_pop(void *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.

Same issues.

  (4) int security_delete_context(void *context)

I still need a way to transform the cachefilesd context into the kernel's
context.  See patch:

   Subject: [Linux-cachefs] [PATCH 12/16] CacheFiles: Get the SID under which
	the CacheFiles module should operate [try #3]

However, this seems to add a fairly generic tranformation, so that could be
generalised:

  (5) int security_xfrm_to_kernel_context(void *from, void **_to);

Woof. What are you transforming from? 

quoted

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

I got the impression that Casey thought much of this was tied to SELinux, but
rereading his/her

"His" is preferred.

emails, I'm not so certain.  Maybe that's sufficient. 
Casey?

I did get the impression that your initial design was focused
on SELinux, and that the implications of alternative LSM modules
had not been very high on your priority list. It's clear from
your responses that you are taking the issue seriously. Thank you.

However, I've realised a problem (as outlined above) with what I've got.
Namely its stack isn't necessarily deep enough.  Alternatively, nfsd perhaps
should suppress caching on what it reads.

That's the really nice thing about cans of worms.
They come in six-packs.



Casey Schaufler
casey@schaufler-ca.com