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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 20 Nov 2006 13:49:53 -0500
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	David Howells <dhowells@...hat.com>
Cc:	James Morris <jmorris@...ei.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>, trond.myklebust@....uio.no,
	selinux@...ho.nsa.gov, linux-kernel@...r.kernel.org,
	aviro@...hat.com, steved@...hat.com
Subject: Re: [PATCH 12/19] CacheFiles: Permit a process's create SID to be
	overridden

On Wed, 2006-11-15 at 16:23 +0000, David Howells wrote:
> James Morris <jmorris@...ei.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.

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/