Re: [PATCH 3/3] p9auth: add p9auth driver

[Kyle Moffett <kyle@moffetthome.net>]

On Wed, Apr 21, 2010 at 15:15, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Serge E. Hallyn" <serue@us.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