linux-kernel - Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

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]

Message-Id: <1197566877.20226.130.camel@moss-spartans.epoch.ncsc.mil>
Date:	Thu, 13 Dec 2007 12:27:57 -0500
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	David Howells <dhowells@...hat.com>
Cc:	casey@...aufler-ca.com, Karl MacMillan <kmacmill@...hat.com>,
	viro@....linux.org.uk, hch@...radead.org,
	Trond.Myklebust@...app.com, linux-kernel@...r.kernel.org,
	selinux@...ho.nsa.gov, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM
	settings for task actions [try #2]

On Thu, 2007-12-13 at 17:01 +0000, David Howells wrote:
> Stephen Smalley <sds@...ho.nsa.gov> wrote:
> 
> > They would correspond with the operations provided by the /dev/cachefiles
> > interface, at the granularity you want to support distinctions to be made.
> 
> Can this be made simpler by the fact that /dev/cachefiles has its own unique
> label (cachefiles_dev_t).

That lets you control who can use the interface at all, but not what
operations they can invoke on it.

> > Could just be a single 'setcontext' permission if that is all you want to
> > control distinctly, or could be a permission per operation.
> 
> There is only one operation that makes sense to have a permission: "set
> context and begin caching".
> 
> All the other operations on a file descriptor attached to /dev/cachfiles are
> necessary for there to be a managed cache at all, and given that you've
> managed to open /dev/cachefiles that's sufficient access for those, I think.

Do any of the interfaces allow a task to act on a cache other than one
it has created?  How does the task identify the desired cache?  What if
there is a conflict between multiple tasks asking for the same cache?

> > If the latter, you don't really need a label for the object, and can
> > just use the supplied context/secid as the object of the permission
> > check, ala:
> > 	rc = avc_has_perm(tsec->sid, secid, SECCLASS_CACHEFILES,
> > CACHEFILES__SETCONTEXT);
> 
> Ummm.   I was under the impression that the target SID had to be a member of
> target class.

Not necessarily.

secid is being applied as the acting context for the cachefiles kernel
module, so the above makes sense, even though there isn't really any
"object" in view here.  Abstractly, the question we are asking above is:

Can this task set the context of the cachefiles kernel module to this
value?

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