site_archiver@lists.apple.com Delivered-To: darwin-kernel@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@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@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@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@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com
This email sent to tlambert@apple.com
_______________________________________________ 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