All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: David Howells <dhowells@redhat.com>,
	viro@ftp.linux.org.uk, hch@infradead.org,
	Trond.Myklebust@netapp.com, sds@tycho.nsa.gov,
	casey@schaufler-ca.com
Cc: linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov,
	linux-security-module@vger.kernel.org, dhowells@redhat.com
Subject: Re: [PATCH 00/22] Introduce credential record
Date: Fri, 21 Sep 2007 08:36:49 -0700 (PDT)	[thread overview]
Message-ID: <718847.32805.qm@web36601.mail.mud.yahoo.com> (raw)
In-Reply-To: <20070921144703.8323.50492.stgit@warthog.procyon.org.uk>


--- David Howells <dhowells@redhat.com> wrote:

> 
> 
> Hi Al, Christoph, Trond, Stephen, Casey,
> 
> Here's a set of patches that implement a very basic set of COW credentials. 
> It
> compiles, links and runs for x86_64 with EXT3, (V)FAT, NFS, AFS, SELinux and
> keyrings all enabled.  Most other filesystems are disabled, apart from things
> like proc.  It is not intended to completely cover the kernel at this point.
> 
> The cred struct contains the credentials that the kernel needs to act upon
> something or to create something.  Credentials that govern how a task may be
> acted upon remain in the task struct.
> 
> In essence, the introduction of the cred struct separates a task's subjective
> context (the authority with which it acts) from its objective context (the
> authorisation required by others that want to act upon it), and permits
> overriding of the subjective context by a kernel service so that the service
> can act on the task's behalf to do something the task couldn't do on its own
> authority.
> 
> Because keyrings and effective capabilities can be installed or changed in
> one
> process by another process, they are shadowed by the cred structure rather
> than
> residing there.  Additionally, the session and process keyrings are shared
> between all the threads of a process.  The shadowing is performed by
> update_current_cred() which is invoked on entry to any system call that might
> need it.
> 
> A thread's cred struct may be read by that thread without any RCU precautions
> as only that thread may replace the its own cred struct.  To change a
> thread's
> credentials, dup_cred() should be called to create a new copy, the copy
> should
> be changed, and then set_current_cred() should be called to make it live. 
> Once
> live, it may not be changed as it may then be shared with file descriptors,
> RPC
> calls and other threads.  RCU will be used to dispose of the old structure.
> 
> 
> The four patches are:
> 
>  (1) Introduce struct cred and migrate fsuid, fsgid, the groups list and the
>      keyrings pointer to it.
> 
>  (2) Introduce a security pointer into the cred struct and add LSM hooks to
>      duplicate the information pointed to thereby and to free it.
> 
>      Make SELinux implement the hooks, splitting out some the task security
>      data to be associated with struct cred instead.
> 
>  (3) Migrate the effective capabilities mask into the cred struct.
> 
>  (4) Provide a pair of LSM hooks so that a kernel service can (a) get a
>      credential record representing the authority with which it is permitted
> to
>      act, and (b) alter the file creation context in a credential record.
> 
> In addition, as this works with cachefiles, I've included all the FS-Cache,
> CacheFiles, NFS and AFS patches.
> 
> To substitute a temporary set of credentials, the cred struct attached to the
> task should be altered, like so:
> 
> 	int get_privileged_creds(...)
> 	{
> 		/* get special privileged creds */
> 		my_special_cred = get_kernel_cred("cachefiles", current);
> 		change_create_files_as(my_special_cred, my_cache_dir);
> 	}
> 
> 	int do_stuff(...)
> 	{
> 		struct cred *cred;
> 
> 		/* rotate in the new creds, saving the old */
> 		cred = __set_current_cred(get_cred(my_special_cred));
> 
> 		do_privileged_stuff();
> 
> 		/* restore the old creds */
> 		set_current_cred(cred);
> 	}
> 
> One thing I'm not certain about is how this should interact with /proc, which
> can display some of the stuff in the cred struct.  I think it may be
> necessary
> to have a real cred pointer and an effective cred pointer, with the contents
> of
> /proc coming from the real, but the effective governing what actually goes
> on.

I think you want the effective values to show up in /proc.



Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com>
To: David Howells <dhowells@redhat.com>,
	viro@ftp.linux.org.uk, hch@infradead.org,
	Trond.Myklebust@netapp.com, sds@tycho.nsa.gov,
	casey@schaufler-ca.com
Cc: linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov,
	linux-security-module@vger.kernel.org, dhowells@redhat.com
Subject: Re: [PATCH 00/22] Introduce credential record
Date: Fri, 21 Sep 2007 08:36:49 -0700 (PDT)	[thread overview]
Message-ID: <718847.32805.qm@web36601.mail.mud.yahoo.com> (raw)
In-Reply-To: <20070921144703.8323.50492.stgit@warthog.procyon.org.uk>


--- David Howells <dhowells@redhat.com> wrote:

> 
> 
> Hi Al, Christoph, Trond, Stephen, Casey,
> 
> Here's a set of patches that implement a very basic set of COW credentials. 
> It
> compiles, links and runs for x86_64 with EXT3, (V)FAT, NFS, AFS, SELinux and
> keyrings all enabled.  Most other filesystems are disabled, apart from things
> like proc.  It is not intended to completely cover the kernel at this point.
> 
> The cred struct contains the credentials that the kernel needs to act upon
> something or to create something.  Credentials that govern how a task may be
> acted upon remain in the task struct.
> 
> In essence, the introduction of the cred struct separates a task's subjective
> context (the authority with which it acts) from its objective context (the
> authorisation required by others that want to act upon it), and permits
> overriding of the subjective context by a kernel service so that the service
> can act on the task's behalf to do something the task couldn't do on its own
> authority.
> 
> Because keyrings and effective capabilities can be installed or changed in
> one
> process by another process, they are shadowed by the cred structure rather
> than
> residing there.  Additionally, the session and process keyrings are shared
> between all the threads of a process.  The shadowing is performed by
> update_current_cred() which is invoked on entry to any system call that might
> need it.
> 
> A thread's cred struct may be read by that thread without any RCU precautions
> as only that thread may replace the its own cred struct.  To change a
> thread's
> credentials, dup_cred() should be called to create a new copy, the copy
> should
> be changed, and then set_current_cred() should be called to make it live. 
> Once
> live, it may not be changed as it may then be shared with file descriptors,
> RPC
> calls and other threads.  RCU will be used to dispose of the old structure.
> 
> 
> The four patches are:
> 
>  (1) Introduce struct cred and migrate fsuid, fsgid, the groups list and the
>      keyrings pointer to it.
> 
>  (2) Introduce a security pointer into the cred struct and add LSM hooks to
>      duplicate the information pointed to thereby and to free it.
> 
>      Make SELinux implement the hooks, splitting out some the task security
>      data to be associated with struct cred instead.
> 
>  (3) Migrate the effective capabilities mask into the cred struct.
> 
>  (4) Provide a pair of LSM hooks so that a kernel service can (a) get a
>      credential record representing the authority with which it is permitted
> to
>      act, and (b) alter the file creation context in a credential record.
> 
> In addition, as this works with cachefiles, I've included all the FS-Cache,
> CacheFiles, NFS and AFS patches.
> 
> To substitute a temporary set of credentials, the cred struct attached to the
> task should be altered, like so:
> 
> 	int get_privileged_creds(...)
> 	{
> 		/* get special privileged creds */
> 		my_special_cred = get_kernel_cred("cachefiles", current);
> 		change_create_files_as(my_special_cred, my_cache_dir);
> 	}
> 
> 	int do_stuff(...)
> 	{
> 		struct cred *cred;
> 
> 		/* rotate in the new creds, saving the old */
> 		cred = __set_current_cred(get_cred(my_special_cred));
> 
> 		do_privileged_stuff();
> 
> 		/* restore the old creds */
> 		set_current_cred(cred);
> 	}
> 
> One thing I'm not certain about is how this should interact with /proc, which
> can display some of the stuff in the cred struct.  I think it may be
> necessary
> to have a real cred pointer and an effective cred pointer, with the contents
> of
> /proc coming from the real, but the effective governing what actually goes
> on.

I think you want the effective values to show up in /proc.



Casey Schaufler
casey@schaufler-ca.com

  parent reply	other threads:[~2007-09-21 15:36 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-21 14:47 [PATCH 00/22] Introduce credential record David Howells
2007-09-21 14:47 ` David Howells
2007-09-21 14:47 ` [PATCH 01/22] CRED: Introduce a COW credentials record David Howells
2007-09-21 14:47 ` [PATCH 02/22] CRED: Split the task security data and move part of it into struct cred David Howells
2007-09-21 14:47   ` David Howells
2007-09-21 14:47 ` [PATCH 03/22] CRED: Move the effective capabilities into the cred struct David Howells
2007-09-21 14:47   ` David Howells
2007-09-21 14:47 ` [PATCH 04/22] CRED: Request a credential record for a kernel service David Howells
2007-09-21 14:47   ` David Howells
2007-09-21 14:47 ` [PATCH 05/22] FS-Cache: Release page->private after failed readahead David Howells
2007-09-21 14:47   ` David Howells
2007-09-21 14:47 ` [PATCH 06/22] FS-Cache: Recruit a couple of page flags for cache management David Howells
2007-09-21 14:47   ` David Howells
2007-09-21 14:47 ` [PATCH 07/22] FS-Cache: Provide an add_wait_queue_tail() function David Howells
2007-09-21 14:47   ` David Howells
2007-09-21 14:47 ` [PATCH 08/22] FS-Cache: Generic filesystem caching facility David Howells
2007-09-21 14:47 ` [PATCH 09/22] CacheFiles: Add missing copy_page export for ia64 David Howells
2007-09-21 14:47   ` David Howells
2007-09-21 14:47 ` [PATCH 10/22] CacheFiles: Add a hook to write a single page of data to an inode David Howells
2007-09-21 14:47   ` David Howells
2007-09-21 19:30   ` Trond Myklebust
2007-09-21 23:11     ` David Howells
2007-09-21 23:11       ` David Howells
2007-09-21 14:48 ` [PATCH 11/22] CacheFiles: Permit the page lock state to be monitored David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 19:33   ` Trond Myklebust
2007-09-21 23:14     ` David Howells
2007-09-21 23:14       ` David Howells
2007-09-21 14:48 ` [PATCH 12/22] CacheFiles: Export things for CacheFiles David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 14:48 ` [PATCH 13/22] CacheFiles: A cache that backs onto a mounted filesystem David Howells
2007-09-21 14:48 ` [PATCH 14/22] NFS: Use local caching David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 17:00   ` Peter Staubach
2007-09-21 23:22     ` David Howells
2007-09-21 23:22       ` David Howells
2007-09-21 23:37       ` David Howells
2007-09-21 23:37         ` David Howells
2007-09-24 13:31         ` Peter Staubach
2007-09-24 13:31           ` Peter Staubach
2007-09-21 14:48 ` [PATCH 15/22] NFS: Configuration and mount option changes to enable local caching on NFS David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 14:48 ` [PATCH 16/22] NFS: Display local caching state David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 14:48 ` [PATCH 17/22] AFS: Add TestSetPageError() David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 14:48 ` [PATCH 18/22] AFS: Add a function to excise a rejected write from the pagecache David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 14:48 ` [PATCH 19/22] AFS: Improve handling of a rejected writeback David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 14:48 ` [PATCH 20/22] AFS: Implement shared-writable mmap David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 14:48 ` [PATCH 21/22] AF_RXRPC: Save the operation ID for debugging David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 14:48 ` [PATCH 22/22] FS-Cache: Make kAFS use FS-Cache David Howells
2007-09-21 14:48   ` David Howells
2007-09-21 14:58 ` [PATCH 00/22] Introduce credential record David Howells
2007-09-21 14:58   ` David Howells
2007-09-21 15:36 ` Casey Schaufler [this message]
2007-09-21 15:36   ` Casey Schaufler
2007-09-21 15:40   ` David Howells
2007-09-21 15:40     ` David Howells
2007-09-21 16:04     ` Casey Schaufler
2007-09-21 16:04       ` Casey Schaufler
2007-09-21 23:18       ` David Howells
2007-09-21 23:18         ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=718847.32805.qm@web36601.mail.mud.yahoo.com \
    --to=casey@schaufler-ca.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.