Subject: Re: Integrating securelevel and kauth(9)
To: Elad Efrat <elad@NetBSD.org>
From: David Laight <david@l8s.co.uk>
List: tech-security
Date: 03/24/2006 19:01:51
On Fri, Mar 24, 2006 at 07:56:27PM +0200, Elad Efrat wrote:
>
> Giving a code example, if we have something like:
>
> /* Don't allow ioctl() requests if securelevel is > 1 */
> if (securelevel > 1)
> return (EPERM);
>
> It might be replaced with:
>
> /* See if we can issue ioctl() requests */
> if (kauth_authorize_system(curproc->p_cred,
> KAUTH_SYSTEM_DRIVER_IOCTL, NULL) != 0)
> return (EPERM);
>
...
>
> For those who are not too familiar with kauth(9), this authorization
> request will then be dispatched to the default listener for the system
> scope. That listener will perform something like this:
>
> [...]
> error = 0;
> switch (operation) {
> [...]
> case KAUTH_SYSTEM_DRIVER_IOCTL:
> if (securelevel & KAUTH_SYSTEM_DRIVER_IOCTL)
> error = EPERM;
> break;
> [...]
> }
>
> return (error);
While I can see the benefit of having multiple bits, I don't see why
the 'securelevel' stuff ever needs to depend on curproc [1].
Neither can I see why you are suggesting this needs to be checked via
some listening service, and not be a simple bitmask check.
There is a suggestion that this might involve a double process switch....
I worry about the performance costs of this, and the fact that callers
may not be in a position where sleeping is valid.
David
[1] splitting 'suser()' into multiple bits is a separate problem, made
worse by the necessity for 'suid' binaries and trusted path.
Not to say that it wouldn't be worthwhile.
--
David Laight: david@l8s.co.uk