On Wed, 2006-11-15 at 16:23 +0000, David Howells wrote:
> James Morris <[email protected]> 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.
Correct; this is no different than modifying ->fsuid temporarily.
> > 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? 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, and the race in which the rules might change is still a
> possibility I have to deal with.
I don't see any value added by introducing yet another field for the
create SID (unlike the actor SID, where we need to distinguish it for
certain checks where the task is the target rather than the actor), so I
don't advocate this approach.
I still suspect that the task flag approach would have been rather
simpler...
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
