Re: [PATCH 12/19] CacheFiles: Permit a process's create SID to be overridden

[Karl MacMillan <kmacmillan@mentalrootkit.com>]

David Howells wrote:
> James Morris <jmorris@namei.org> wrote:
>
> > Well, the value can be changed at any time, so you could be using a 
> > temporary fscreate value, or your new value could be overwritten 
> > immediately by writing to /proc/$$/attr/fscreate
>
> Ah.  Hmmm.  By whom?  In selinux_setprocattr():
>
> 	if (current != p) {
> 		/* SELinux only allows a process to change its own
> 		   security attributes. */
> 		return -EACCES;
> 	}
>
> But current busy inside the cache and can't do this.
>
> > I think we need to add a separate field for this purpose, which can only 
> > be written to via the in-kernel API and overrides fscreate.
>
> So, like my acts-as security ID patch?
>
> Would it still need to be controlled by MAC policy in that case?

Yes - if we are going to perform some MAC checks for this kernel process 
we need to have all checks performed.

  Doing so is
> a bit of a pain as it means I have a whole bunch of extra failures I still
> need to check for,

This is true for going this route in general rather than simply 
bypassing MAC. I don't think halfway makes any sense.

 and the race in which the rules might change is still a
> possibility I have to deal with.

I don't think this is a race, it is revocation of access. If you check 
the access at every operation and correctly deal with access failures, 
then this shouldn't be a problem. Yes it is a pain, but that is how 
SELinux is supposed to work.

Karl

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