Message-ID: <w2wf73f7ab81004212157o371c5738o10c8b6ff807ba36a@mail.gmail.com>
Date:	Thu, 22 Apr 2010 00:57:03 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	Ashwin Ganti <ashwin.ganti@...il.com>,
	Greg KH <greg@...ah.com>, rsc@...ch.com, ericvh@...il.com,
	linux-security-module@...r.kernel.org,
	Ron Minnich <rminnich@...il.com>, jt.beard@...il.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrew Morgan <morgan@...nel.org>, oleg@...ibm.com,
	Eric Paris <eparis@...hat.com>, linux-api@...r.kernel.org,
	Randy Dunlap <rdunlap@...otime.net>
Subject: Re: [PATCH 3/3] p9auth: add p9auth driver

On Wed, Apr 21, 2010 at 15:15, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> "Serge E. Hallyn" <serue@...ibm.com> writes:
>
>> Ignoring namespaces for a moment, I guess we could do something like
>>
>> struct credentials_pass {
>>       pid_t global_pid;
>>       unsigned long unique_id;
>>       uid_t new_uid;
>>       gid_t new_gid;
>>       int num_aux_gids;
>>       gid_t aux_gids[];
>> }
>
> This looks surprising like what I am doing in passing uids and pids
> through unix domain sockets.
>
> So if this looks like a direction we want to go it shouldn't be too
> difficult.

Hmm... for an alternative idea:

We have this nice "kernel keyring" infrastructure that lets us stuff
arbitrary things into "keys" and grant/revoke them between processes.
What if we created a relatively generic way for processes to package
up privileges (of whatever form) into a "key" that could be granted to
another process (via UNIX-domain socket)?  Then the other process
would use a setuid()-ish syscall which would instead apply a specific
key as your credentials, possibly including the audit context and/or
namespaces it came from.

By using the keyring system, such tokens could be kept around across
multiple processes easily (as opposed to FDs), in the same style as a
"sudo" ticket file, for example (even with an expiration time).

Types of credentials you could pass around:
  * Capabilities
  * Filesystem UID/GID in a particular UID namespace (for FS operations)
  * Process UID/GID in a particular UID namespace (for kill(), etc)
  * Audit contexts
  * SELinux/etc security labels

All of the above could be optionally limited to effectively require a
bprm-secure-style exec() with specific args.  So for example, instead
of making "/usr/sbin/passwd" a setuid program, you could make it be an
unprivileged helper.  It would connect to a privileged daemon and ask
for a password-change cookie for that particular user.  The daemon
would create what is essentially a "delayed exec" key which grants a
specific UID and capabilities when that process performs an execkey().

So as an example, you could rewrite "sudo" as a partially-privileged
daemon and an unprivileged helper.  The unpriv helper would send
across a request (optionally including the command and environment)
which would be checked by the daemon.  It would then issue a key to
allow the unpriv helper to perform a limited exec.

Another option would be to rewrite network login programs (eg OpenSSH)
to use this for privilege separation.  The listening process would get
a non-expiring key to allow it to exec a partially-privileged
password-checking program.  If the password-checking program likes the
password it generates a single-use key to pass back to the forked
network process that allows it to exec a program as that user.

Cheers,
Kyle Moffett
--
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