site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 12 May 2011, at 10:20, Juuso Salonen wrote:

If code signing is not the answer, are there other options?

Code signing is the only reliable way to check for code identity; every other solution can either be spoofed easily (for example, the binary name or path) or suffers from false positives (for example, a checksum of the binary). You can't call the code signing API directly from your KEXT. The traditional approach is to have a user space helper process that performs code signature verification on your behalf. Your KEXT can then cache the code signing result for the lifetime of the process [1].

I was unable to find any relevant information about using code signing for kext development.

There are four components to this solution: o KEXT -- I presume you already have this under control. o user space helper -- You would typically make this a launchd daemon; if you need help with that, let use know. o code signature checking -- Within your user space helper you can check code signatures using the SecCode API. <Security/SecCode.h> is a good place to start here. o KEXT/user communication -- I typically recommend a kernel control socket <sys/kern_control.h> for this. The tcplognke is a good place to start with kernel control socket. <http://developer.apple.com/library/mac/samplecode/tcplognke/> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware [1] While the validity of a process's signature can change during the lifetime of the process, it's probably not worth worrying about that complexity in your situation. _______________________________________________ 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... This email sent to site_archiver@lists.apple.com