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