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: Rick Macklem <email@hidden>
- Date: Fri, 21 Aug 2009 15:44:56 -0400 (EDT)
On Fri, 21 Aug 2009, Terry Lambert wrote:
On Aug 21, 2009, at 3:47 AM, Andreas Guðmundsson
<email@hidden> wrote:
On Fri, Aug 21, 2009 at 8:30 AM, Quinn<email@hidden> wrote:
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.
It is not possible to actually do what you want, it is only possible to make
it prohibitively expensive for an attacker with a lesser or comparable level
of technology.
Well, although no security mechanism is uncrackable, I can think of a
couple of ways a fairly high level of security could be achieved:
1 - The code could wire into the gssd used by the NFS server. This is
non-trivial to do in a Kext and goes beyond the KPIs, but can be
done. Then, the userland daemon would be assigned a unique
Kerberos principal name that has a keytab entry and the code would
essentially do RPCSEC_GSS or equivalent. (Since the xnu kernel
doesn't have an RPCSEC_GSS implementation, it would be a lot of
work to code up, probably using the xnu NFS code as a guide.)
It's also fun to get initiator credentials from a keytab entry.
Worth the effort...almost certainly not, but the original query
didn't indicate how badly it was needed.
--> If the machine's default keytab file is compromised, it's
busted.
2 - A simpler version of the above would be to do an RPCSEC_GSS like
encrypted checksum on all messages sent on the socket, using a
private key hard coded into the executables. This is a variation
of what Quinn called "security via obscurity" but, if the source
code is being kept secret and the key is well hidden in the
executables, it could work pretty well. (It would also need to
timestamp or seq# the messages to avoid replay attacks.)
I strongly expect that running the daemon as "root" is far more
attractive than either of the above, but...rick
_______________________________________________
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