Re: Authenticated communication between KEXT and a userland client
Re: Authenticated communication between KEXT and a userland client
- Subject: Re: Authenticated communication between KEXT and a userland client
- From: Terry Lambert <email@hidden>
- Date: Thu, 20 Aug 2009 18:58:05 -0700
In general, BSD authorization is unavailable in IOKit land; not only
do you not have a passed down BSD scope for the operation, you also
don't have a vnode in context usually on which you could request an
authorization.
The BSD model is that I have an ACTOR performing OPERATION on OBJECT.
For BSD, it's always:
ACTOR: vfs_context_t OR kauth_cred_t (the latter usually from fg_cred)
OPERATION: a defined set of authorization operations known to kauth
OBJECT: a BSD object, such as a vnode, which has POSIX owner, group,
and mode
If you are in IOKit, you are already past that. If you are running on
an IOWorkLoop thread, you are performing a proxy operation, and
there's no guarantee that whoever you are doing the work on behalf of
is not already dead. If they aren't already dead in that case, it's
probably because you have a task reference at the time the operation
was requested, which is insufficient for identifying the current
credential scope (i.e. you probably grabbed it not for authorization,
but only to keep the address space from being torn down out from under
the IOWorkLoop thread).
The general BSD model for devices is that the authorization occurs at
the point the device is opened, based on a POSIX owner, group, and
mode. Once authorized, operations on that handle remain authorized be
a reference on the kauth_cred_t that requested the initial open
(that's why passing an fd via UNIX domain socket gives away the rights
requested at the time of the open to the receiving process; otherwise,
someone could hand you an fd, and you wouldn't be able to use it
because you had different/reduced rights compared to the process who
opened it).
The closest you can get to this model in IOKit is to require the
IOUserClient open to be privileged, do the open from a privileged
program, then hand it off to the unprivileged client (which is started
by the privileged program which did the open).
This still won't get you explicit POSIX owner, group, mode rights on
the OBJECT that the client (ACTOR) is trying to perform the OPERATION
(open) on at the time, other than to hard code information that
"accidently" corresponds to user/group information in the user
database up in user space, and then fake up a mask.
One suggestion that comes up every once in a while is to have the
driver export a BSD device node instead of using an IOUserClient to
talk to it, at which point the permissions will be enforced in user
space via devfs at the time the device is opened. This still requires
that you figure out the POSIX user, group, mode you want to use. The
mode can generally be selected to be a default; the user and group
could be passed in via the IO Registry, or by the helper that loads
the program (e.g. via plist fields set up by the installer at the time
the software is installed, at the same time the installer creates the
role account which is allowed to talk to the device).
You could also set up a kauth scope specific to your device, and
ensure that the operations are only set up in a synchronous context
(i.e. force a credential reference on the per-thread credential at the
time the operation is called synchronously, or when it it
synchronously enqueued as a work item for processing in the
IOWorkLoop). This still leaves as an exercise for the student how you
would go about ensuring the OBJECT rights information corresponds to
the right thing for you to do the authorization, without some way of
causing persistent BSD owner, group, mode information to be set on the
device somehow (or how, once set, you would cause the information to
remain coherent with the user space database of user information which
is used to create the user space process credential - ACTOR - that
you use to do the check and permit the operation).
Typically people who write IOUserClient code either require root, make
the client robust enough that it doesn't matter who sends data to it
or what data they send, or make the driver only willing to talk to one
client at a time, and make sure their client gets there first by
running it under the system wide launchd.
-- Terry
On Aug 20, 2009, at 1:12 PM, Andreas Guðmundsson wrote:
Well, yes I can do that and in fact I guess I´ll just end up with that
but I had hoped to run my client with less privileges. I´ve thought of
a few things involving either two way communication between the kext
and client, or scenarios where the kext solely examines the client and
makes a decision based on that, in short I´ve not been successful as I
can subvert every scheme I´ve thought of, sucks to be me. Perhaps what
I want just isn´t possible.
What I wanted:
kext and client(not running as root) communicating
prevent a deliberate wrong client from connecting
So do you generally keep the client privileged and in the kext you
assume that a privileged client is to be trusted? I´m fine with that
assumption but I´d really prefer not running my client in the context
of root.
On Thu, Aug 20, 2009 at 10:13 AM, <email@hidden> wrote:
It is possible to restrict socket access only to user land client
running in root’s context. Is that what you are looking for ?
-Sudarshan
On 19/08/09 8:42 PM, "Michael Smith" <email@hidden> wrote:
On Aug 19, 2009, at 6:10 AM, Andreas Guðmundsson wrote:
Hi, I have a kext and a userland client communicating with sockets.
Now I'd like to be sure that I'm communicating with the correct
client
so I want the kext to authenticate the client. How can this be done
properly?
Andreas,
Before it's possible to give you a useful answer, you need to
explain what you mean by the "correct client".
Do you want to prevent an accidental wrong client, or are you
trying to ensure that a deliberate wrong client won't be able to
use your interface?
= Mike
--
Ars longa, vita brevis, occasio praeceps, experimentum periculosum,
iudicium difficile -- Hippocrates
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden