Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:Authorization once, and .dmg

At 1:40 AM +0100 10/17/02, Sak Wathanasin wrote:
I have no idea what everyone else is doing, but I simply don't do the "self-repair". Maybe I've missed something but the appl doesn't need to be suid root: it asks the user for a user-name/passwd and if the supplied credentials are those of an administrator, the tool (that needs the privs) will succeed, otherwise it will not.

IMHO an appl that changes itself into one that is suid root creates more of a security problem than it solves and makes the appl needlessly complicated.

This works fine for some tools, but is inappropriate for others.
Nobody wants to be constantly interrupted to authenticate every
time they run a common tool. Thus many built-in unix tools
like ping are suid root.

In my case, I've created a number of small unix tools
that can be set to suid root. The first tool which I've
dubbed "authorize" interprets any command line arguments
as file paths to other tools that need to be set suid root
(chmod followed by chown).

When my application is run, it checks whether each tool is
present, restores it from a backup if needed, and invokes
each tool that needs to run as suid root requesting its
identification and status (whether it is root) to build
a list of tools that need to be authorized. If the list is
non-empty, it then uses the Authorization Framework to run
my authorize tool as root passing the list of paths to be
authorized. [The authorize tool itself should never be suid root.]

The tools live in the application bundle and each one includes
a backup copy (.bak). When the application is copied from the
Finder, any files set to suid root are not copied so it uses
these backups to self repair. Normally the user is only asked
to authenticate once the first time the application is run or
copied to a new location. For Jaguar, the entire bundle will
fail to copy if a single element is owned by root. For this case,
I provide an "Unauthorize Tools..." option to allow copying the
application bundle.

Notice the application goes to some effort to identify each tool
before authorizing it. I don't want to authorize a trojan horse
if someone replaces one of my tools in the bundle. Ideally, you
would sign the file containing each tool but this won't work
because the files may change when your tools are pre-bound.

The tools themselves are relatively safe because they do so little.
Each tool performs one simple task like opening a raw socket,
loading my NKE, or running another privileged tool and piping
back the results. Generally 30 lines of code or less.

From my perspective, Apple has taken a small problem that was
relatively easy to work around and made it a UI mess. You
can no longer reliably copy or backup files using the Finder.
Even if you don't need any suid root tools, if your application uses
an NKE you have the same problem since NKE's must be owned by
root in order to load under Mac OS X.

Users really like drag-and-drop installs that just work or self repair.
They don't like installers that leave droppings in protected directories
all over their system. They don't like features that stop working with
no explanation or debugging file permission conflicts.

I'd be glad to see Apple incorporate my sources as sample code
that addresses the real issues developers face.

- Peter
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.
References: 
 >Authorization once, and .dmg (From: Jen Beaven <email@hidden>)
 >Re:Authorization once, and .dmg (From: Sak Wathanasin <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.