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: Andreas Guðmundsson <email@hidden>
- Date: Fri, 21 Aug 2009 10:37:59 +0000
2009/8/21 Terry Lambert <email@hidden>:
> 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.
What I´m currently doing is exactly that, I require the client to be
root and I only accept one client at a time. Thanks for a thorough
response.
>
> -- 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