How to embed framework in app with setuid helper

  • My app has always included my embedded framework using @executablepath, per
    the documentation on embedding frameworks, and it has always worked fine.

    Now I've added a setuid authorization helper tool in my application
    package's Resources folder. When I try to run my app, I get these error
    messages in the console.:

    "dyld: Library not loaded: @executablepath<path to my embedded framework>"

      "Referenced from: <path to my app executable>"

      "Reason: unsafe use of @executablepath in <path to my app executable>
    with setuid binary"

      "... Exited abnormally: Trace/BPT trap"

    What can I do about this? Must I copy my setuid helper into the user's
    Application Support folder as per Apple's MoreAuthSample sample code?

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • Well, your framework is probably writeable by non-root users, meaning
    that someone could go in and replace your framework with some
    malicious code, which would then be blindly loaded by your setuid
    binary and executed.

    Once you understand this, you should understand the solution.

    -- Finlay

    On 15/09/2007, Bill Cheeseman <bill...> wrote:
    > My app has always included my embedded framework using @executablepath, per
    > the documentation on embedding frameworks, and it has always worked fine.
    >
    > Now I've added a setuid authorization helper tool in my application
    > package's Resources folder. When I try to run my app, I get these error
    > messages in the console.:
    >
    > "dyld: Library not loaded: @executablepath<path to my embedded framework>"
    >
    > "Referenced from: <path to my app executable>"
    >
    > "Reason: unsafe use of @executablepath in <path to my app executable>
    > with setuid binary"
    >
    > "... Exited abnormally: Trace/BPT trap"
    >
    > What can I do about this? Must I copy my setuid helper into the user's
    > Application Support folder as per Apple's MoreAuthSample sample code?
    >
    > --
    >
    > Bill Cheeseman - <bill...>
    > Quechee Software, Quechee, Vermont, USA
    > www.quecheesoftware.com
    >
    > PreFab Software - www.prefabsoftware.com
    >
  • on 2007-09-15 7:42 AM, Finlay Dobbie at <finlay.dobbie...> wrote:

    > Well, your framework is probably writeable by non-root users, meaning
    > that someone could go in and replace your framework with some
    > malicious code, which would then be blindly loaded by your setuid
    > binary and executed.
    >
    > Once you understand this, you should understand the solution.

    I'm not sure I understand your hint. The embedded framework was indeed
    read-write for all. But changing it to read-only for all yields the same
    error.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • On 15/09/2007, at 11:53 PM, Bill Cheeseman wrote:

    > on 2007-09-15 7:42 AM, Finlay Dobbie at <finlay.dobbie...> wrote:
    >
    >> Well, your framework is probably writeable by non-root users, meaning
    >> that someone could go in and replace your framework with some
    >> malicious code, which would then be blindly loaded by your setuid
    >> binary and executed.
    >>
    >> Once you understand this, you should understand the solution.
    >
    > I'm not sure I understand your hint. The embedded framework was indeed
    > read-write for all. But changing it to read-only for all yields the
    > same
    > error.

    It's probably that anyone can write to the directory which means
    anyone can replace the framework with something else.

    You should try and avoid dynamically linking to local frameworks in
    your setuid tool if you can help it. If there's something that you
    must have, you could try creating a static library and linking to that.

    - Chris
  • on 2007-09-15 4:15 PM, Chris Suter at <chris...> wrote:

    > You should try and avoid dynamically linking to local frameworks in
    > your setuid tool if you can help it. If there's something that you
    > must have, you could try creating a static library and linking to that.

    The setuid tool and the framework are completely unrelated. The framework is
    embedded in the app to provide certain functionality. The setuid tool is
    embedded in the framework for the sole purpose of running the accessibility
    API AXMakeProcessTrusted() function, which must run as root, to make the
    main application's executable "trusted".

    So maybe I need to think up some way to let Xcode know that they have
    nothing to do with one another.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • on 2007-09-15 8:00 PM, Bill Cheeseman at <bill...> wrote:

    > The setuid tool is
    > embedded in the framework for the sole purpose of running the accessibility
    > API AXMakeProcessTrusted() function, which must run as root, to make the
    > main application's executable "trusted".

    I misspoke. The setuid tool is embedded in the application, not the
    framework.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • on 2007-09-16 5:27 AM, Bill Cheeseman at <bill...> wrote:

    > on 2007-09-15 8:00 PM, Bill Cheeseman at <bill...> wrote:
    >
    >> The setuid tool is
    >> embedded in the framework for the sole purpose of running the accessibility
    >> API AXMakeProcessTrusted() function, which must run as root, to make the
    >> main application's executable "trusted".
    >
    > I misspoke. The setuid tool is embedded in the application, not the
    > framework.

    I have a confirmed diagnosis, but no cure.

    It turns out that this problem is the result of an interaction between the
    Accessiblity API's AXMakeProcessTrusted() function and dyld.

    My application makes its executable "trusted" by the Accessibility API. It
    does this by running an embedded setuid tool as root. The setuid tool runs
    AXMakeProcessTrusted() against my main application executable. My
    investigations have confirmed that AXMakeProcessTrusted() works by changing
    my application executable's gid to "accessibility". I relaunch my
    application by using another embedded tool to call -[NSWorkspace
    launchApplication:]. This Cocoa method apparently calls execve(), which
    eventually calls issetugid() when dyld tries to load my embedded framework.
    The issetugid() function returns 1 when it sees that the executable's gid
    has been changed, and dyld kills the app in mid-relaunch for security
    reasons when it sees that the framework is embedded.

    If I've got this right, it means that AXMakeProcessTrusted() can't be used
    with any application that has embedded frameworks, unless I'm willing to
    tell the user to relaunch my app from the Finder manually instead of
    relaunching it for my user automatically. (Unless I can figure out how to
    relaunch my app using AppleScript, or using the same Cocoa method or
    execve() and divorcing the relaunched process from its launching parent
    process by fiddling with the environment.)

    Any feedback or suggestions about how to do this would be much appreciated.
    Since it turns out that this is an accessibility issue, I'll inquire on the
    accessibility list, too.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • On Sep 17, 2007, at 5:17 PM, Bill Cheeseman wrote:

    > on 2007-09-16 5:27 AM, Bill Cheeseman at <bill...> wrote:
    >
    >> on 2007-09-15 8:00 PM, Bill Cheeseman at <bill...> wrote:
    >>
    >>> The setuid tool is
    >>> embedded in the framework for the sole purpose of running the
    >>> accessibility
    >>> API AXMakeProcessTrusted() function, which must run as root, to
    >>> make the
    >>> main application's executable "trusted".
    >>
    >> I misspoke. The setuid tool is embedded in the application, not the
    >> framework.
    >
    > I have a confirmed diagnosis, but no cure.
    >
    > It turns out that this problem is the result of an interaction
    > between the
    > Accessiblity API's AXMakeProcessTrusted() function and dyld.
    >
    > My application makes its executable "trusted" by the Accessibility
    > API. It
    > does this by running an embedded setuid tool as root. The setuid
    > tool runs
    > AXMakeProcessTrusted() against my main application executable. My
    > investigations have confirmed that AXMakeProcessTrusted() works by
    > changing
    > my application executable's gid to "accessibility". I relaunch my
    > application by using another embedded tool to call -[NSWorkspace
    > launchApplication:]. This Cocoa method apparently calls execve(),
    > which
    > eventually calls issetugid() when dyld tries to load my embedded
    > framework.
    > The issetugid() function returns 1 when it sees that the
    > executable's gid
    > has been changed, and dyld kills the app in mid-relaunch for security
    > reasons when it sees that the framework is embedded.
    >
    > If I've got this right, it means that AXMakeProcessTrusted() can't
    > be used
    > with any application that has embedded frameworks, unless I'm
    > willing to
    > tell the user to relaunch my app from the Finder manually instead of
    > relaunching it for my user automatically. (Unless I can figure out
    > how to
    > relaunch my app using AppleScript, or using the same Cocoa method or
    > execve() and divorcing the relaunched process from its launching
    > parent
    > process by fiddling with the environment.)
    >
    > Any feedback or suggestions about how to do this would be much
    > appreciated.
    > Since it turns out that this is an accessibility issue, I'll
    > inquire on the
    > accessibility list, too.

    If you go with an AppleScript solution, the following technote may be
    useful since it deals with launching scripts that require admin
    privileges:

    <http://developer.apple.com/technotes/tn2002/tn2065.html>

    ___________________________________________________________
    Ricky A. Sharp        mailto:<rsharp...>
    Instant Interactive(tm)  http://www.instantinteractive.com
previous month september 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today