August 2009 - Darwin-kernel

Re: getPhysicalSegment out of 32b range kernel panic
by Duane Murphy 24 Aug '09

24 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com PGP.sig

1 0

Re: getPhysicalSegment out of 32b range kernel panic
by Duane Murphy 24 Aug '09

24 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com PGP.sig

1 0

Re: Authenticated communication between KEXT and a userland client
by Rick Macklem 21 Aug '09

21 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Fri, 21 Aug 2009, Terry Lambert wrote: I suspect this aswell and I´d very much appreciate being pointed to some concrete reading material on the subject. 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 (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com On Aug 21, 2009, at 3:47 AM, Andreas Guðmundsson <andreassonurgudmunds(a)gmail.com> wrote: On Fri, Aug 21, 2009 at 8:30 AM, Quinn<eskimo1(a)apple.com> 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. 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.

1 0

Re: Authenticated communication between KEXT and a userland client
by Terry Lambert 21 Aug '09

21 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I suspect this aswell and I´d very much appreciate being pointed to some concrete reading material on the subject. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Aug 21, 2009, at 3:47 AM, Andreas Guðmundsson <andreassonurgudmunds(a)gmail.co m> wrote: On Fri, Aug 21, 2009 at 8:30 AM, Quinn<eskimo1(a)apple.com> 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. 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. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Authenticated communication between KEXT and a userland client
by Andreas Guðmundsson 21 Aug '09

21 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YhnXMJ4Rp3AKnic/rzYP1Bv8YcV+eaxKosCTjLiAuPE=; b=b+GWhcyGzDgcWVaEZ6Dist12yLoBHofvZNVnbdNIcJ1u+xOEF3u70vcAxTUlyDFfHI +GvMRRErlzUVXGK6gXFlzO5k3bSQckOk31C4WOvUUF/M5Kxg9IJpsV9cf+6QPLj2vXaa /D9cwwXjFkfWN0JShRFCPHKA77NBkDMEPO+fI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WeXAzx2NGQLycjEJg94CW03J+EpATfnWcSRTncY7r5GdBiAMrfj0dib9ewo2Bki11s 7a3e5jJS3OK828A0l5yaVJtO0NZc2qcGP0zfmetulQP5EZhMI3Hosdq9eAv6rl1gkLGo wW86r2TnL4uAzpIeRxplKOKV1iUx4V/A52GCg= On Fri, Aug 21, 2009 at 8:30 AM, Quinn<eskimo1(a)apple.com> 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 (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Authenticated communication between KEXT and a userland client
by Andreas Guðmundsson 21 Aug '09

21 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SPz9yESw092fp1P5Z/fiB8u4khV0RUqgmmouND3xSl8=; b=jU16DbRVzOkChoJpVaW+GzyklLZCnIXXvjBqc/yO5JZXLZkNw+4Fk41HWtYgJzTUH8 sOK1I7fSYFupa3nORsurowcRiQwUyXK1MdhBKZPOGm6pD4Xi3je3XhnUUIEqxqdxpriM 3BUFZQifwdzmDHSxShNM13jX5/n8mNeYm9kFw= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IIJBDyaekbG4OwfMiXfV3x67DnBqPQmtsD+ltI8owjlReAYuDUOCM5hohj4YMsAilS 0jsAqclFozOb0d2HfYHjQTn6JgAwkh9ojEfCJSpTEcZhFoYc977sDDgbqEY8WsVdcoMx prdexk0t++IixEk7onjQo709cqwUvL2sEEXFE= 2009/8/21 Terry Lambert <tlambert(a)apple.com>: > In general, BSD authorization is unavailable in IOKit land; not only do you > not have a passed down BSD scope for the operation, you also don't have a > vnode in context usually on which you could request an authorization. > > The BSD model is that I have an ACTOR performing OPERATION on OBJECT. For > BSD, it's always: > > ACTOR: vfs_context_t OR kauth_cred_t (the latter usually > from fg_cred) > OPERATION: a defined set of authorization operations known to > kauth > OBJECT: a BSD object, such as a vnode, which has POSIX owner, > group, and mode > > If you are in IOKit, you are already past that. If you are running on an > IOWorkLoop thread, you are performing a proxy operation, and there's no > guarantee that whoever you are doing the work on behalf of is not already > dead. If they aren't already dead in that case, it's probably because you > have a task reference at the time the operation was requested, which is > insufficient for identifying the current credential scope (i.e. you probably > grabbed it not for authorization, but only to keep the address space from > being torn down out from under the IOWorkLoop thread). > > The general BSD model for devices is that the authorization occurs at the > point the device is opened, based on a POSIX owner, group, and mode. Once > authorized, operations on that handle remain authorized be a reference on > the kauth_cred_t that requested the initial open (that's why passing an fd > via UNIX domain socket gives away the rights requested at the time of the > open to the receiving process; otherwise, someone could hand you an fd, and > you wouldn't be able to use it because you had different/reduced rights > compared to the process who opened it). > > The closest you can get to this model in IOKit is to require the > IOUserClient open to be privileged, do the open from a privileged program, > then hand it off to the unprivileged client (which is started by the > privileged program which did the open). > > This still won't get you explicit POSIX owner, group, mode rights on the > OBJECT that the client (ACTOR) is trying to perform the OPERATION (open) on > at the time, other than to hard code information that "accidently" > corresponds to user/group information in the user database up in user space, > and then fake up a mask. > > One suggestion that comes up every once in a while is to have the driver > export a BSD device node instead of using an IOUserClient to talk to it, at > which point the permissions will be enforced in user space via devfs at the > time the device is opened. This still requires that you figure out the > POSIX user, group, mode you want to use. The mode can generally be selected > to be a default; the user and group could be passed in via the IO Registry, > or by the helper that loads the program (e.g. via plist fields set up by the > installer at the time the software is installed, at the same time the > installer creates the role account which is allowed to talk to the device). > > You could also set up a kauth scope specific to your device, and ensure that > the operations are only set up in a synchronous context (i.e. force a > credential reference on the per-thread credential at the time the operation > is called synchronously, or when it it synchronously enqueued as a work item > for processing in the IOWorkLoop). This still leaves as an exercise for the > student how you would go about ensuring the OBJECT rights information > corresponds to the right thing for you to do the authorization, without some > way of causing persistent BSD owner, group, mode information to be set on > the device somehow (or how, once set, you would cause the information to > remain coherent with the user space database of user information which is > used to create the user space process credential - ACTOR - that you use to > do the check and permit the operation). > > Typically people who write IOUserClient code either require root, make the > client robust enough that it doesn't matter who sends data to it or what > data they send, or make the driver only willing to talk to one client at a > time, and make sure their client gets there first by running it under the > system wide launchd. What I´m currently doing is exactly that, I require the client to be root and I only accept one client at a time. Thanks for a thorough response. > > -- Terry > > On Aug 20, 2009, at 1:12 PM, Andreas Guðmundsson wrote: >> >> Well, yes I can do that and in fact I guess I´ll just end up with that >> but I had hoped to run my client with less privileges. I´ve thought of >> a few things involving either two way communication between the kext >> and client, or scenarios where the kext solely examines the client and >> makes a decision based on that, in short I´ve not been successful as I >> can subvert every scheme I´ve thought of, sucks to be me. Perhaps what >> I want just isn´t possible. >> >> What I wanted: >> kext and client(not running as root) communicating >> prevent a deliberate wrong client from connecting >> >> So do you generally keep the client privileged and in the kext you >> assume that a privileged client is to be trusted? I´m fine with that >> assumption but I´d really prefer not running my client in the context >> of root. >> >> >> On Thu, Aug 20, 2009 at 10:13 AM, <Sudarshan_Swamy(a)mcafee.com> wrote: >>> >>> It is possible to restrict socket access only to user land client running >>> in root’s context. Is that what you are looking for ? >>> >>> -Sudarshan >>> >>> On 19/08/09 8:42 PM, "Michael Smith" <drivers(a)mu.org> wrote: >>> >>> >>> On Aug 19, 2009, at 6:10 AM, Andreas Guðmundsson wrote: >>> >>> Hi, I have a kext and a userland client communicating with sockets. >>> Now I'd like to be sure that I'm communicating with the correct client >>> so I want the kext to authenticate the client. How can this be done >>> properly? >>> >>> Andreas, >>> >>> Before it's possible to give you a useful answer, you need to explain >>> what you mean by the "correct client". >>> >>> Do you want to prevent an accidental wrong client, or are you trying to >>> ensure that a deliberate wrong client won't be able to use your interface? >>> >>> = Mike >>> >>> >>> -- >>> Ars longa, vita brevis, occasio praeceps, experimentum periculosum, >>> iudicium difficile -- Hippocrates >>> >>> >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com >> >> This email sent to tlambert(a)apple.com > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Authenticated communication between KEXT and a userland client
by Quinn 21 Aug '09

21 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… 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(a)lists.apple.com

1 0

Re: Authenticated communication between KEXT and a userland client
by Terry Lambert 21 Aug '09

21 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- Terry Well, yes I can do that and in fact I guess I´ll just end up with that but I had hoped to run my client with less privileges. I´ve thought of a few things involving either two way communication between the kext and client, or scenarios where the kext solely examines the client and makes a decision based on that, in short I´ve not been successful as I can subvert every scheme I´ve thought of, sucks to be me. Perhaps what I want just isn´t possible. What I wanted: kext and client(not running as root) communicating prevent a deliberate wrong client from connecting So do you generally keep the client privileged and in the kext you assume that a privileged client is to be trusted? I´m fine with that assumption but I´d really prefer not running my client in the context of root. -Sudarshan On 19/08/09 8:42 PM, "Michael Smith" <drivers(a)mu.org> wrote: On Aug 19, 2009, at 6:10 AM, Andreas Guðmundsson wrote: Andreas, = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… In general, BSD authorization is unavailable in IOKit land; not only do you not have a passed down BSD scope for the operation, you also don't have a vnode in context usually on which you could request an authorization. The BSD model is that I have an ACTOR performing OPERATION on OBJECT. For BSD, it's always: ACTOR: vfs_context_t OR kauth_cred_t (the latter usually from fg_cred) OPERATION: a defined set of authorization operations known to kauth OBJECT: a BSD object, such as a vnode, which has POSIX owner, group, and mode If you are in IOKit, you are already past that. If you are running on an IOWorkLoop thread, you are performing a proxy operation, and there's no guarantee that whoever you are doing the work on behalf of is not already dead. If they aren't already dead in that case, it's probably because you have a task reference at the time the operation was requested, which is insufficient for identifying the current credential scope (i.e. you probably grabbed it not for authorization, but only to keep the address space from being torn down out from under the IOWorkLoop thread). The general BSD model for devices is that the authorization occurs at the point the device is opened, based on a POSIX owner, group, and mode. Once authorized, operations on that handle remain authorized be a reference on the kauth_cred_t that requested the initial open (that's why passing an fd via UNIX domain socket gives away the rights requested at the time of the open to the receiving process; otherwise, someone could hand you an fd, and you wouldn't be able to use it because you had different/reduced rights compared to the process who opened it). The closest you can get to this model in IOKit is to require the IOUserClient open to be privileged, do the open from a privileged program, then hand it off to the unprivileged client (which is started by the privileged program which did the open). This still won't get you explicit POSIX owner, group, mode rights on the OBJECT that the client (ACTOR) is trying to perform the OPERATION (open) on at the time, other than to hard code information that "accidently" corresponds to user/group information in the user database up in user space, and then fake up a mask. One suggestion that comes up every once in a while is to have the driver export a BSD device node instead of using an IOUserClient to talk to it, at which point the permissions will be enforced in user space via devfs at the time the device is opened. This still requires that you figure out the POSIX user, group, mode you want to use. The mode can generally be selected to be a default; the user and group could be passed in via the IO Registry, or by the helper that loads the program (e.g. via plist fields set up by the installer at the time the software is installed, at the same time the installer creates the role account which is allowed to talk to the device). You could also set up a kauth scope specific to your device, and ensure that the operations are only set up in a synchronous context (i.e. force a credential reference on the per-thread credential at the time the operation is called synchronously, or when it it synchronously enqueued as a work item for processing in the IOWorkLoop). This still leaves as an exercise for the student how you would go about ensuring the OBJECT rights information corresponds to the right thing for you to do the authorization, without some way of causing persistent BSD owner, group, mode information to be set on the device somehow (or how, once set, you would cause the information to remain coherent with the user space database of user information which is used to create the user space process credential - ACTOR - that you use to do the check and permit the operation). Typically people who write IOUserClient code either require root, make the client robust enough that it doesn't matter who sends data to it or what data they send, or make the driver only willing to talk to one client at a time, and make sure their client gets there first by running it under the system wide launchd. On Aug 20, 2009, at 1:12 PM, Andreas Guðmundsson wrote: On Thu, Aug 20, 2009 at 10:13 AM, <Sudarshan_Swamy(a)mcafee.com> wrote: It is possible to restrict socket access only to user land client running in root’s context. Is that what you are looking for ? Hi, I have a kext and a userland client communicating with sockets. Now I'd like to be sure that I'm communicating with the correct client so I want the kext to authenticate the client. How can this be done properly? Before it's possible to give you a useful answer, you need to explain what you mean by the "correct client". Do you want to prevent an accidental wrong client, or are you trying to ensure that a deliberate wrong client won't be able to use your interface? -- Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile -- Hippocrates This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Authenticated communication between KEXT and a userland client
by Andreas Guðmundsson 20 Aug '09

20 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fmIVceifeCTdrOLFGB8IcwyVHGHguhCC4LFm/rmU3e8=; b=kNCLRNYdhDka8nZxgbnDb5adzDalA+XChuc3ULQIRxAfNNwfTf+XUI3Td623Lbb/2D qNvTyNg2UNwEvJk8pNohJ/BBOd38lwU7Oac/NKZ/x9pPSgq85FjbdvddWGTsxgbAcJdB GjD+BvRLQi/BcPmY7aUlebcBogRLQzSJDLvZc= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xikmWl/xAOuMp+ScYwuW6wMWwNU6nNdjcEYmiP6bsAZjtzTLF5EOP60zymJVmYq6sD +XqzHrD18V+ol4tzsL1tzP3DdKcZ4PyBB3TIup+SHhjf90vWIbPYlFRgwwqDvphNS8wC J2LRs7jJhzh6LgNqDabP38dzcBrEXRGrCp8GE= Well, yes I can do that and in fact I guess I´ll just end up with that but I had hoped to run my client with less privileges. I´ve thought of a few things involving either two way communication between the kext and client, or scenarios where the kext solely examines the client and makes a decision based on that, in short I´ve not been successful as I can subvert every scheme I´ve thought of, sucks to be me. Perhaps what I want just isn´t possible. What I wanted: kext and client(not running as root) communicating prevent a deliberate wrong client from connecting So do you generally keep the client privileged and in the kext you assume that a privileged client is to be trusted? I´m fine with that assumption but I´d really prefer not running my client in the context of root. On Thu, Aug 20, 2009 at 10:13 AM, <Sudarshan_Swamy(a)mcafee.com> wrote: > It is possible to restrict socket access only to user land client running in root’s context. Is that what you are looking for ? > > -Sudarshan > > On 19/08/09 8:42 PM, "Michael Smith" <drivers(a)mu.org> wrote: > > > On Aug 19, 2009, at 6:10 AM, Andreas Guðmundsson wrote: > > Hi, I have a kext and a userland client communicating with sockets. > Now I'd like to be sure that I'm communicating with the correct client > so I want the kext to authenticate the client. How can this be done > properly? > > Andreas, > > Before it's possible to give you a useful answer, you need to explain what you mean by the "correct client". > > Do you want to prevent an accidental wrong client, or are you trying to ensure that a deliberate wrong client won't be able to use your interface? > > = Mike > > > -- > Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile -- Hippocrates > > > > > > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Authenticated communication between KEXT and a userland client
by Sudarshan_Swamy＠McAfee.com 20 Aug '09

20 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: Acog34YOQ8UH5YJTRUW5JQxxR+J0NAAn032p Thread-topic: Authenticated communication between KEXT and a userland client It is possible to restrict socket access only to user land client running in root’s context. Is that what you are looking for ? -Sudarshan On 19/08/09 8:42 PM, "Michael Smith" <drivers(a)mu.org> wrote: On Aug 19, 2009, at 6:10 AM, Andreas Guðmundsson wrote: Hi, I have a kext and a userland client communicating with sockets. Now I'd like to be sure that I'm communicating with the correct client so I want the kext to authenticate the client. How can this be done properly? Andreas, Before it's possible to give you a useful answer, you need to explain what you mean by the "correct client". Do you want to prevent an accidental wrong client, or are you trying to ensure that a deliberate wrong client won't be able to use your interface? = Mike -- Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile -- Hippocrates _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0