Applets within Wrapper that need root/administrative privileges
Applets within Wrapper that need root/administrative privileges
- Subject: Applets within Wrapper that need root/administrative privileges
- From: Bill Bumgarner <email@hidden>
- Date: Thu, 19 Dec 2002 09:36:23 -0500
On Wednesday, Dec 18, 2002, at 16:18 US/Eastern, Peter Sichel wrote:
My application requires a bunch of small supporting applets that must
be configured as SUID root in order for the application to work.
I use the "First Run" process to complete the installation by
configuring these applets.
Do the applets really need to be SUID root or could you use the
Authorization framework to request permission to launch the applets as
root?
Even if the applets are daemons-- i.e. applets that startup as the app
starts up (or as the user logs in) and are expected to run for the
lifespan of the application (or user session)-- there are significant
advantages with going through the Authorization APIs as to just using
SUID.
In particular, it allows the user to control the permissions of the
application through the KeyChain application. The user can require a
password everytime the SUID-type permissions are required or indicate
that the app is trusted all the time. If the SUID applets are
launched on a regular basis, the user can also indicate that the
authorization rights should expire after the system wakes from sleep or
some period of time has elapsed.
It also allows you to leave the applets in the app wrapper, thereby
avoiding the upgrade versioning problems and multiple version problems
you mentioned in the original message.
However, there are security risks with going this route. Notably, the
applets will likely be writable by the user and, hence, be vulnerable
to attack.
As such, your application should test to make sure that the applets
have not been modified. The command line tools md5 and sum are useful
for this and both use algorithms that can be found in source form that
can easily be plugged into your application. Of course, someone could
replace the applets and change the checksum in your application binary,
but that is well beyond the casual cracker.
There are alternatives to straight checksums. You could use something
like PGP to sign the binaries with a key pair issued specifically for
the application-- done correctly, this would be significantly harder to
subvert than a straight checksum (but, with determination, could still
be subverted). I'm not going to remotely pretend to be an expert on
using crypto to perform validation of app components-- there are
numerous wonderful resources on the net for this kind of information
(and, if you have a license to PGP Personal Desktop, the documentation
includes an "Intro to Cryptography" that is both very well written and
contains a tremendous wealth of information on the subject).
Apple has a tech note on the subject. I would post a link, but I don't
have net access. The tech note is specifically related to the
Authorization APIs.
If you really do need to go the SUID route, an installer that can
modify the permissions is probably the best route and has some
advantages in and of itself. In particular, it would allow a user with
admin privileges to install the application such that
non-administrative users can use the app.
b.bum
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.