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

On Mon, 2007-08-13 at 11:54 +0100, David Howells wrote:

quoted

Casey Schaufler [off-list ref] wrote:

quoted

Sigh. So it's not only SELinux specific, but RedHat specific as well.

*Blink*.  How did you come to that conclusion?

quoted

quoted

  (3) The cache driver wants to access the files in the cache, but it's
      running in the security context of either the aforementioned

random

quoted

quoted

quoted

      process, or one of FS-Cache's thread pool.

I think that this is the point you should attack. Control the security
characteristics of the cache driver properly and you shouldn't need the
complexity that you're asking to introduce.

How?  The cache driver acts on behalf of someone else.  That someone else

has

quoted

one security context, but the cache itself has to have a different context

so

quoted

that the cache can be shared.

Furthermore, the cache driver doesn't have a security context per se.

quoted

quoted

      This security context, however, doesn't necessarily give it the
      rights to access what's in the cache, so the driver has to be
      permitted to act as a context appropriate to accessing the cache,
      without changing the overall security context of the random

process

quoted

quoted

quoted

      (which would impact things trying to act on that process - kill()
      for example).

Can you run the cache as an independent thread and send it messages
rather than trying to do things in the context of the calling process?
I know that that involves extra bookkeeppingg, but it's lots safer.

It introduces more complexity, which I believe you were just arguing

against

quoted

above...  It also incurs more kernel threads - which I really really want

to

quoted

avoid.

I would rank the complexity and resource overhead of the act-as stuff in

LSM

quoted

(or at least in SELinux) as much less than what you're suggesting.

As it stands, the FS-Cache layer has a pool of threads that CacheFiles

makes

quoted

use of, but this can't be bound to the security of a specific cache because
there may be more than one cache of more than one cache driver type.

quoted

Yes, and the SELinux semantics for what label to give a file don't
help much, either. The problem with the "act_as" interfaces is that
I wouldn't expect them to be any more reliable than the old access()
system call, which never really gave you a helpful answer.

I don't see how act_as compares to access().

quoted

Ideally you want to be running in the right context to create the
new file so that no one can use it and then label it "correctly"
and make it available.

That sounds like it'd be the complexity thing again...

quoted

quoted

Part of the problem is that the VFS does not pass around the security
context as which the VFS routines act, but rather gets them from the
task_struct.

That's by design. 

I suspect that's more by the fact that security wasn't particularly thought
about when these interfaces were first written.  As with everything in the
kernel, it might be negotiable.

quoted

The cache driver is a unique case with an unusual function. It's pretty
obvious that the kernel architecture, the VFS architecture, LSM, SELinux,
NFS and pretty much everyone else has given no thought whatever to the
implications of their designs on file system cacheing. For all concerned,
I'll say "sorry 'bout that".

Meaning you think I should just give up on this?

How about I reduce the interface I'm proposing to two functions:

  (1) int security_act_as(struct task_struct *context)

	Temporarily make the current process act as the given task, including,
	for example, for SELinux, the security ID with which this task acts on
	things, and the security ID with which this task creates files.

I don't see how that helps with nfsd assuming the label of a remote
client process.

Well, assuming that nfsd assuming the label of a remote client is
a good idea ...

    newtask = taskstructdup(current);
    newtask->security = security_of_client;
    security_act_as(newtask);
    ... do interesting things ...
    security_act_as_self(); /* security_act_as(NULL); ? */
    cleanup_newtask(...)

... would be the basic flow. For what it's worth, and the whole
issue is being debated with gusto elsewhere, there are enough
problems with nfsd using this approach that it may not be worth
holding anything up for. 

quoted

  (2) int security_act_as_self(void);

	Restore the context as which we're asking.

This would mean that the task's security context would have to be able to

store

quoted

acting security IDs for everything, but I don't think that's too much of a
stretch resourcewise.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Casey Schaufler
casey@schaufler-ca.com