Re: More KAUTH_GENERIC_ISSUSER replacements

[Elad Efrat <elad%NetBSD.org@localhost>]

On Thu, May 7, 2009 at 5:56 AM, YAMAMOTO Takashi 
<yamt%mwd.biglobe.ne.jp@localhost> wrote:

>> If we add the file-system name, it means we're expecting security
>> models to check for a specific file-system name (or names) and just
>> "know" that it allows one feature or another.
>> I would rather we ask the security model, "can these credentials be
>> used to mount a file-system that allows user mapping?".
>
> then, "mounting a umapfs." is not a good description. :)

True, that's why (I think) mrg@ suggested
KAUTH_REQ_SYSTEM_MOUNT_USERMAP: "mount a file-system that allows user
mapping". ;) But:

>>> if you want a check for changing credentials,
>>> it doesn't really belong to KAUTH_SYSTEM_MOUNT, i guess.

After giving it some more thought, I think we should indicate a change
of credentials like you suggest. What I don't know is what action (or
request) to use.

At the moment we have KAUTH_PROCESS_SETID for that, but it requires a
"struct proc *" argument, which we don't have in our context since we
mount a file-system that anyone can use eventually, so we're not
changing credentials for a specific process.

I might be looking too much into a rather rarely unused file-system,
but here's my proposal:

  - Keep a reference to the caller's credentials when mounting inside
"struct umap_mount", these will be called "mounter creds"
  - Remove the kauth(9) check in umapfs_mount()
  - Make umap_subr.c:umap_mapids() return an int (ie., allow it to
fail), and check return value in callers
  - Modify umap_mapids() to issue a kauth(9) call to ask, "can
<mounter_creds> be used to modify <credp> to <desired_creds>?" --
either using a new kauth(9) action or KAUTH_PROCESS_SETID (and use
curlwp->l_proc as the process). If we use a new action, we can either
make it take kauth_cred_ts as the "old" (credp) and "new"
(desired_creds) creds and then construct credentials in umap_mapids(),
or just create requests like SETID::{,E}UID,{,E}GID,GROUPS and issue
several calls. The latter will work for other places as well
(sys_seteuid(), etc.)

What I think that buys us is a more appropriate and less specific
solution, as well as a subsystem (umap) that will always follow the
security policy. Using KAUTH_PROCESS_SETID will also cover other cases
as mentioned.

Thoughts? :)

Thanks,

-e.