Re: Linking frameworks in a trusted app
Re: Linking frameworks in a trusted app
- Subject: Re: Linking frameworks in a trusted app
- From: Michael Ash <email@hidden>
- Date: Mon, 12 Oct 2009 22:47:48 -0400
On Oct 12, 2009, at 5:08 PM, Paul Middlin wrote:
In order to use the accessibility API's, we've followed the examples
to make our app trusted. We made a helper app, used the
Authentication services to launch it, and called AXMakeProcessTrusted
(). Pretty much the same as how google did it:
http://code.google.com/p/command-q/source/browse/trunk/MakeProcessTrustedMain.m
Once trusted, our app won't run because we use some frameworks, like
Sparkle. We get this complaint in the crash log:
Dyld Error Message:
Library not loaded: @loader_path/../Frameworks/Sparkle.framework/
Versions/A/Sparkle
Referenced from: /Users/username/sandbox/OurApp/build/Debug/
OurApp.app/Contents/MacOS/OurApp
Reason: unsafe use of @loader_path in /Users/username/sandbox/
OurApp/build/Debug/OurApp.app/Contents/MacOS/OurApp with restricted
binary
I tried setting the "Install Name" to use @rpath, and then setting
the rpath (Runpath Search Paths) to @loader_path/../Frameworks/, but
that doesn't work. Well, it works until you mark your app trusted
using AxMakeProcessTrusted(), and then it claims it can't find the
library anymore.
Ideas? Any other way to get accessibility support for my app without
making the user go "enable access for assistive devices" for all
apps in the system preferences?
I had heard maybe you can add your app to the accessibility group
during install, but didn't find much info on it.
Accessibility trusted processes are implemented by setting the binary
to be owned by the accessibility group and making the binary be setgid
(automatically set the group ID to that of the binary's owner on
startup, regardless of the group ID of who executed it, much like
setuid does for the user).
The trouble is that this is pretty much fundamentally incompatible
with all sorts of things the system does to try to make setuid/setgid
binaries more secure. That's what you're running afoul of here.
In this particular case, you're not allowed to load frameworks from
relative paths, because a hypothetical attacker can very easily
control what those paths will end up being at runtime, and can thus
use this mechanism to execute his own code with the privilege of the
group.
My personal recommendation is to split your Accessibility code off
into a separate program, written to do nothing but talk to
Accessibility and do IPC up to your main app, and make *that* trusted
instead of your entire application. This moves the troublesome setgid
stuff out of your application and into a single-purpose binary which
won't be doing anything else.
Depending on how your code is structured this may not be easy at all,
but as far as I know it's really the only way to get around this
problem short of giving up AXMakeProcessTrusted completely.
(You could certainly set your application owner and the setgid bit
during installation in order to mimic what AXMakeProcessTrusted does,
but you'll just end up with the same problems, so it's no solution.)
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden