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: <23942.1197569044@redhat.com>
Date:	Thu, 13 Dec 2007 18:04:04 +0000
From:	David Howells <dhowells@...hat.com>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	dhowells@...hat.com, 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]

Stephen Smalley <sds@...ho.nsa.gov> wrote:

> Do any of the interfaces allow a task to act on a cache other than one
> it has created?

No.

> How does the task identify the desired cache?

Each file descriptor opened creates one separate cache instance.  Any commands
sent over that filedescriptor affect only the cache instance it is attached
to; similarly, any status data you read only refers to that one cache
instance.

Closing the file descriptor makes the cache go away as far as the kernel is
concerned.  The cachefiles daemon retains its cache dev file descriptor for
the lifetime of the daemon.

> What if there is a conflict between multiple tasks asking for the same
> cache?

As far as the cache daemon is concerned, the file descriptor is its handle to
the cache so the conflict does not arise.

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

So the following (taken from cachefilesd.te):

	allow cachefilesd_t cachefiles_var_t : file { getattr rename unlink };

says, for example, allow:

	avc_has_perm("cachefilesd_t",
		     "cachefiles_var_t",
		     SECCLASS_FILE,
		     FILE__RENAME,
		     ...);

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