Re: [PATCH 00/16] Permit filesystem local caching [try #3]


--- Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:

On Mon, 2007-08-13 at 11:54 +0100, David Howells wrote:
Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:

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

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

(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
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
one security context, but the cache itself has to have a different context
so
that the cache can be shared.

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

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
(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
above... It also incurs more kernel threads - which I really really want
to
avoid.

I would rank the complexity and resource overhead of the act-as stuff in
LSM
(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
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.

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().

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...

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.

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.


(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
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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.





Casey Schaufler
casey@xxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 00/16] Permit filesystem local caching [try #3]
    ... so I asked advice of the Red Hat security people, who, naturally, pointed me ... NFS goes to the cache to attempt to read the data from there prior to ... The cache driver wants to access the files in the cache, ... running in the security context of either the aforementioned random ...
    (Linux-Kernel)
  • Re: [PATCH 00/16] Permit filesystem local caching [try #3]
    ... running in the security context of either the aforementioned random ... The cache driver acts on behalf of someone else. ... one security context, but the cache itself has to have a different context so ... permitted to act as a context appropriate to accessing the cache, ...
    (Linux-Kernel)
  • Re: [PATCH 00/16] Permit filesystem local caching [try #3]
    ... running in the security context of either the aforementioned random ... The cache driver acts on behalf of someone else. ... one security context, but the cache itself has to have a different context so ... permitted to act as a context appropriate to accessing the cache, ...
    (Linux-Kernel)
  • Re: [PATCH 00/16] Permit filesystem local caching [try #3]
    ... running in the security context of either the aforementioned random ... The cache driver acts on behalf of someone else. ... one security context, but the cache itself has to have a different context so ... permitted to act as a context appropriate to accessing the cache, ...
    (Linux-Kernel)
  • Re: [PATCH 00/16] Permit filesystem local caching [try #3]
    ... so I asked advice of the Red Hat security people, who, naturally, pointed me ... NFS goes to the cache to attempt to read the data from there prior to ... The cache driver wants to access the files in the cache, ... running in the security context of either the aforementioned random ...
    (Linux-Kernel)