Authorisation within Cocoa apps
Authorisation within Cocoa apps
- Subject: Authorisation within Cocoa apps
- From: Tim Hewett <email@hidden>
- Date: Sat, 30 Oct 2004 14:25:39 +0100
Hi,
I've been checking out the AuthSample developer example.
I need my app to be able to authorise root privileges and have
been trying to find the best way.
Context:
In the AuthSample it states "keep in mind that you should never
create a full GUI application that runs as setuid root". However
I have found that a setuid-to-root app can temporarily "push back"
root privileges using:
seteuid( getuid() );
This forces your run-time privileges back to those of the user
running the app (see "man seteuid"). If you subsequently perform:
seteuid( 0 );
then you regain the effective root privileges you started out with,
i.e. the "saved set-user-ID".
If you perform
setuid( getuid() );
then you lose the ability to pull back effective root privileges,
handy for forking and exec-ing child processes, in case someone
replaces the child executable with a "rm -r /" or similar to exploit
the saved effective root permission.
Therefore your app can deny itself the effective root privileges it
has been given, but can allow them to be restored if the
Authorisation Services dialog says that the user has provided the
correct identity info.
My plan:
I plan to have my Cocoa app run with the setuid bit set so it has
effective root permissions, no matter who it is run by. I plan to
push this back at the top of main() using seteuid( getuid() ), so
the app loses the ability to do anything without authorisation.
I plan to add a menu item to enable root privileges by calling
AuthorizationCopyRights(), as in the AuthSample example,
to use the pre-authorisation facility to decide whether the user
is able to provide the authorisation user and password. If they
can then when an appropriate child process is created,
seteuid( 0 ) will be called to provide the child with root access,
otherwise setuid( getuid() ) will be called to completely remove
any possibility of root access. The Cocoa app process will never
call seteuid( 0 ) itself, this will only ever be done in the child
process just after it has been forked, so the Cocoa app will only
ever have the permissions of the user that ran it.
All files in the application hierarchy from the Contents folder
down will be owned by root, with group & other perms set to
r-x (so that executables in the Resources directory, which are
used by the Cocoa parent, cannot be deleted and replaced with
a "do anything" app), this being setup as part of the postflight
script when the application is installed.
It seems to me that this is a watertight approach, I can't see how
someone could get around this, there doesn't appear to be a
security loophole. Anyone know any better???
Cheers,
Tim.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden