headers
Elad Efrat | 15 May 2006 23:03
Picon

Dividing securelevel implications to kauth(9) scopes

Hi,

Let's make this one short...

kauth(9) is now merged, let's start using it. We already "discussed"
moving securelevel implementation to use kauth(9) -- no comments on
this one, please; contact me off-list if something is not clear.

For that we need to create action identifiers to be used in
authorization calls, and probably some scopes, too.

I looked at where securelevel is used in the kernel and summed it up
to a list. It's available online at:

	http://www.bsd.org.il/netbsd/security.levels

The format is very clear and simple: for every securelevel 0, 1, 2
I listed the implications, and divided them to those that affect the
"TCB" (or, the original intention of securelevel, as it appears in
The Design and Implementation of 4.4BSD) and other misc. stuff.

In square brackets listed the kauth(9) scope I suggest. The new scopes
suggested are "network", "driver", and "machdep".

For example, if "changing packet filter rules" is suggested to use
the "network" scope, a conditional can be:

	if (kauth_authorize_network(cred, KAUTH_NETWORK_CHGPFIL) != 0)
		return (EPERM);
(Continue reading)

Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 16 May 2006 02:03
Picon

Re: Dividing securelevel implications to kauth(9) scopes

> I looked at where securelevel is used in the kernel and summed it up
> to a list. It's available online at:
> 
> 	http://www.bsd.org.il/netbsd/security.levels
> 
> The format is very clear and simple: for every securelevel 0, 1, 2
> I listed the implications, and divided them to those that affect the
> "TCB" (or, the original intention of securelevel, as it appears in
> The Design and Implementation of 4.4BSD) and other misc. stuff.
> 
> In square brackets listed the kauth(9) scope I suggest. The new scopes
> suggested are "network", "driver", and "machdep".

i think chflags shouldn't be "generic".

can you propose operations and their arguments as well?
to me, it isn't clear how "driver" scope operations will be, for example.

YAMAMOTO Takashi
Permalink | Reply | 0 comments |
headers
Elad Efrat | 16 May 2006 20:38
Picon

Re: Dividing securelevel implications to kauth(9) scopes

YAMAMOTO Takashi wrote:

> i think chflags shouldn't be "generic".

"vnode"?

> can you propose operations and their arguments as well?
> to me, it isn't clear how "driver" scope operations will be, for example.

The arguments passed to the authorization wrappers are supposed to
provide a context for the listener to make a decision. Every operation
will have its own set of arguments.

For example, we have the following code in sys/dev/tc/stic.c:

	static int
	sticopen(dev_t dev, int flag, int mode, struct lwp *l)
	{
		struct stic_info *si;
		int s;

		if (securelevel > 0)
			return (EPERM);
	[...]

Where's it's clear we have no context needed to make a decision, so
the arguments can all be NULL.

The above is similar (just change the securelevel being conditionalized)
for all securelevel references in sys/dev *except*
(Continue reading)

Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 17 May 2006 11:21
Picon

Re: Dividing securelevel implications to kauth(9) scopes

> > i think chflags shouldn't be "generic".
> 
> "vnode"?

yea, it sounds better.

> > can you propose operations and their arguments as well?
> > to me, it isn't clear how "driver" scope operations will be, for example.
> 
> The arguments passed to the authorization wrappers are supposed to
> provide a context for the listener to make a decision. Every operation
> will have its own set of arguments.
> 
> For example, we have the following code in sys/dev/tc/stic.c:
> 
> 	static int
> 	sticopen(dev_t dev, int flag, int mode, struct lwp *l)
> 	{
> 		struct stic_info *si;
> 		int s;
> 
> 		if (securelevel > 0)
> 			return (EPERM);
> 	[...]
> 
> Where's it's clear we have no context needed to make a decision, so
> the arguments can all be NULL.

i don't think it's so obvious.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elad Efrat | 17 May 2006 20:32
Picon

Re: Dividing securelevel implications to kauth(9) scopes

YAMAMOTO Takashi wrote:

> i don't think it's so obvious.
> 
> to define a kauth action, we need to figure out
> why sticopen should be prohibited.
> otherwise, we end up to have KAUTH_DRIVER_STICOPEN,
> which is a poor choice, IMO.

See below:

> besides, it can be done by listening more generic actions like "open".
> in that case, you want to pass vnode pointer or dev_t, so that listener
> can check if it's a "dangerous" device.

That's the idea. The list is just where we *currently* check for
the securelevel.

-e.

--

-- 
Elad Efrat
Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 18 May 2006 03:50
Picon

Re: Dividing securelevel implications to kauth(9) scopes

> > besides, it can be done by listening more generic actions like "open".
> > in that case, you want to pass vnode pointer or dev_t, so that listener
> > can check if it's a "dangerous" device.
> 
> That's the idea. The list is just where we *currently* check for
> the securelevel.

ok, fine.
your comment "it's clear we have no context needed" made me think
something like KAUTH_DRIVER_STICOPEN. :-)

YAMAMOTO Takashi
Permalink | Reply | 0 comments |

Gmane