|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: Integrating securelevel and kauth(9)
From: David Laight (david
l8s.co.uk)
Date: Fri Mar 24 2006 - 13:01:51 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]