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:47:35 +0000
On Fri, Aug 21, 2009 at 8:30 AM, Quinn<email@hidden> wrote:
> At 20:12 +0000 20/8/09, Andreas Guðmundsson wrote:
>>
>> kext and client(not running as root) communicating
>> prevent a deliberate wrong client from connecting
>
> The problem here is your definition of "wrong client". What exactly is a
> wrong client? How can you tell? AFAIK you really only have two options:
Yes, the definiton of "wrong client" is exactly the problem.
>
> o some sort of security-through-obscurity mechanism -- That is, the client
> and server exchange some token that authorises the client with the server.
> This is not a good approach.
I agree and I´m not willing to rely on security through obscurity.
>
> o code signing -- The server could require the client to be signed. [This
> is hard to do from a KEXT but we're ignoring practical issues at the
> moment.]
Ignoring the practical is just fine, I was just wondering.
> The problem here is that, while you can verify the code signature
> of a process, you can't guarantee that the process hasn't been subverted (at
> least in the current code signing architecture). That is, there are a
> variety of ways that a malicious user can force code to load within your
> client process without breaking its code signature.
Yes, I'm aware of that.
>
> In summary, AFAIK there's no good way, even in theory, to do what you want,
> and you will have to rethink your requirements.
I suspect this aswell and I´d very much appreciate being pointed to
some concrete reading material on the subject.
Like I stated in an earlier reply I think I´ll go with my current
solution which is to keep the client privileged and accept only one
connection at a time.
_______________________________________________
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