site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com kext and client(not running as root) communicating prevent a deliberate wrong client from connecting S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... At 20:12 +0000 20/8/09, Andreas Guðmundsson wrote: 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: 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. 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.] 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. In summary, AFAIK there's no good way, even in theory, to do what you want, and you will have to rethink your requirements. This email sent to site_archiver@lists.apple.com