[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <718847.32805.qm@web36601.mail.mud.yahoo.com>
Date: Fri, 21 Sep 2007 08:36:49 -0700 (PDT)
From: Casey Schaufler <casey@...aufler-ca.com>
To: David Howells <dhowells@...hat.com>, viro@....linux.org.uk,
hch@...radead.org, Trond.Myklebust@...app.com, sds@...ho.nsa.gov,
casey@...aufler-ca.com
Cc: linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
linux-security-module@...r.kernel.org, dhowells@...hat.com
Subject: Re: [PATCH 00/22] Introduce credential record
--- David Howells <dhowells@...hat.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@...aufler-ca.com
-
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/
Powered by blists - more mailing lists