I'm building a kext for an extra layer of security on OS X (built around KAtuh). I'm using a client in userspace that connects to the kext over sockets (as advised by Apple), and basically controls the kext. Because the product is supposed to provide extra security for OS X, it is important that it is "as secure as possible" against attacks. One attack vector is the following: A malicious process impersonates the client and sends malicious control data to the kext, disabling the security mechanism.. I want to prevent this by doing authentication upon connection. Here are my solutions:
Run the client as root, use CTL_FLAG_PRIVILEGED flag to ensure only root clients can connect to the kext. I'm not sure if I want to have my client run in privileged mode (again: extra attack vector).
Let the kext be connected to only one client. However, this is easily by-passable.
Ideally, I want to verify the identity of the client that connects through static int ctl_connect(kern_ctl_ref ctl_ref, struct sockaddr_ctl *sac, void **unitinfo). How can I do this?
I can also do packet authentication in static int ctl_set(kern_ctl_ref ctl_ref, u_int32_t unit, void *unitinfo, int opt, void *data, size_t len), however, I would have to come up with a dynamic shared secret. I was thinking about secret = SHA256(getUDID()), but AFAIK there are no crypto KPI's available, neither a way to getUDID() from kernelspace.
Are there any other idea's on doing "proper" authentication of clients?
I have asked Apple's Developer Tech Support this question, and they have said the only supported way to restrict user client access to kexts is to distinguish between root and non-root processes.
Personally, for the purposes of reducing the attack surface, it would indeed be useful to drop user client privileges. The Linux way of checking for a specific group membership seems like it should work on OS X too. (For example, you typically need to be part of the 'kvm' group to use the KVM virtualisation technology on Linux.) The only way to become a member of the group is via root privileges (setting up the Launch Daemon's GroupName requires root privileges) so this should be secure. I have yet to try this myself, but I've got 2 projects where this would make sense so I'll give it a go and will update this answer with my findings.