On Wed, Apr 21, 2010 at 15:15, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
> "Serge E. Hallyn" <serue@xxxxxxxxxx> 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-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
