Casey Schaufler <casey@schaufler-ca.com> wrote:

quoted text
> Could you use "object context" instead of "victimisation context"?
> It would be in better keeping with traditional security jargon.

If you wish.  Personally, I find it clearer than object or subject.

quoted text
> > The separation is necessary for a few reasons:
> > 
> >  (1) The task victimisation context must *not* be changed by a temporary
> >      override of the action and creation contexts for purposes such as
> >      cachefiles.
> 
> That would be for the LSM to decide, not the file system.

Filesystem?  CacheFiles is acting on behalf of a filesystem and must override
the context that that filesystem was using, so that it can access a different
filesystem.

quoted text
> While I concede that it is unlikely that you are going to want to use the
> same security attributes for your "object" and your "subject"

99.99% probable that I will want a different subjective context for talking to
the cache to the objective context of the task I'm doing work on behalf of.

quoted text
> I also suggest that it is probable that the "object" attributes will want to
> change in the case of an filesystem daemon as well, 

What daemon are you referring to?

You've misunderstood, I think.  Consider readpages.  CacheFiles really wants to
run in the process context of whoever called readpages.  The main reason for
this is one of performance: readpages() is called an awful lot, and we don't
want to be changing process context at least twice per call if we can avoid it.

quoted text
> and that the filesystem code by itself can't know what's correct.

Indeed.  I have mentioned that I intend to create a patch to provide an LSM
hook by which a kernel service can ask the LSM module for a new cred struct,
appropriate to that service.  That way, all details of SIDs, secids,
transformations, etc are hidden inside the LSM module.

quoted text
> Assuming that the LSM goes along with the notion you could do that
> with a task struct, too.

Sigh.  Only by saving and restoring the complete credential context from/to the
task struct.

quoted text
> So it sounds like what you'd be happiest with would be a separate task
> struct hand crafted to he the right "object" and "subject" attributes.

Exchanging task structs is highly impractical, I think.

quoted text
> Couldn't you set up a task to do the overridden operations?

Performance.

quoted text
> Yes, but the LSM writer now has to maintain two full security blobs
> even if the system doesn't want cachefs or nfs.

This is actually the simpler and cleaner solution.  It has been assumed,
generally, to this point that subjective context == objective context, but we
have two cases where we need to break that assumption.

quoted text
> You could have done the same thing passing the task instead of a cred.

? I didn't mention passing a cred, did I?

quoted text
> And I'm reluctantly withdrawing my objection to exporting secid's across the
> LSM interface

Actually, I think you were right.  I shouldn't be exposing secids like that.
There's no requirement for an LSM to have such a concept.

quoted text
> I don't see any way to get around the LSM being involved, even with
> secid's.

Of course the LSM must be involved, but secids aren't needed.

quoted text
> Only the LSM can decide what is appropriate for an override value. Maybe all
> you need is
> 
>     int security_task_godlikesecid(u32 *secid)

No, all I really need is something like:

	struct cred *security_get_kernel_service_cred(const char *name);

And maybe:

	int security_create_files_as(struct cred *, struct inode *);

So that I can say I want to be able to create files that look the same as that
inode there.  The LSM can then check that the subjective context in the cred
struct is allowed to do that.

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