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:	Wed, 15 Nov 2006 12:52:07 -0500
From:	Karl MacMillan <kmacmillan@...talrootkit.com>
To:	David Howells <dhowells@...hat.com>
CC:	James Morris <jmorris@...ei.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	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

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