James Carlson wrote:
> I'm working on the NWAM 0.5 ("picea") updates, and I've run into a
> security-related issue on which I need some advice and/or comments.
>
> The current NWAM 0 code in Nevada looks through getutxent(3C) for an
> entry with ut_line == "console" and ut_host == ":0". The ut_user for
> that entry is assumed to be the console user, who is authorized to
> make changes to the network. It uses zenity to get in touch with that
> user.
>
> That code is all being ripped out, and replaced with a GUI that is
> launched with the logged in user's ID, and that uses a door to
> communicate with nwamd.
>
> This means that nwamd must now determine (from a door call) whether
> the caller has the right to change network parameters (such as setting
> up interfaces, tearing them down, selecting wireless access points,
> and so on).
>
> I could just scan getutxent as the old code did, but this seems really
> ungood. An alternative would be to call getuseruid(3SECDB), match out
> the "profiles" keyword, separate out the profiles list, call
> getprofnam(3SECDB) on each one, match out the "privs" keyword, compute
> the privileges with priv_str_to_set(3C), and finally check for
> PRIV_SYS_NET_CONFIG.
>
> That seems like a lot of busy work, and I'm not sure that doing this
> is entirely "right" from a security perspective.
>
> Are there other alternatives that I'm missing? Perhaps something
> simpler?
If you want to determine whether the _user_ has the right to do
something, the usual approach is to check for an authorization rather
than a privilege. You would use chkauthattr() for that.
Krishna Yenduri wrote:
> You can use the following calls to do that -
> door_ucred(&cred);
> ucred_getprivset(cred, pset);
> priv_ismember(pset, PRIV_SYS_NET_CONFIG);
>
> nscd code is a good example.
That will tell you if the calling _process_ has this privilege, but if I
understand the situation correctly, we already know that it does not.
The proposal above was to examine the user's profile entries to
determine if he could potentially run a process with this privilege, but
that's not consistent with the way we usually determine the rights a
user has.
This is exactly the problem that authorizations were designed to solve.
Scott
