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: Thu, 20 Aug 2009 20:12:48 +0000
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