Executing privileged work using exec
Executing privileged work using exec
- Subject: Executing privileged work using exec
- From: OL&L Lists <email@hidden>
- Date: Thu, 13 May 2004 20:33:14 -0700
I saw this posted to the Apple Java dev mailing list and would like
to get someone at Apple's (namely) Quinn's take on it. Does the
Authorization Framework really use exec to do its work? I thought
Apple's security team said this was a no-no.
Thanks,
-m
===================================
Date: Thu, 13 May 2004 18:34:58 -0700
To: email@hidden
From: Greg Guerin <email@hidden>
Subject: Re: Specifying alternate dylib paths in Java
>
Calling exec to execute privileged operations is a very very bad idea
>
and is discouraged by Apple's Security Team and by DTS.
BY strange coincidence, that's exactly how the Authentication and
Authorization framework does its work. It executes a specified file using
a setuid-root process. The setuid-root process's execution is controlled
by the Authenticate dialog, which is presented and managed by the security
server, which runs as root. So ultimately only root can grant access to
the setuid-root process, but it's still all done with exec, so I"m not sure
how bad it can be.
What *IS* a bad idea is the willy-nilly proliferation of setuid-root
executables. Without the controlled access of the security server, that's
the only way (other than 'sudo', which has its own problems) one can
perform root-privileged operations.
>
There has to be a C dylib because we use Apple's recommended way of
>
calling the helper tool which is to use
>
MoreSecExecuteRequestInHelperTool which is in one of Apple's
>
libraries. We use the JNI lib to interface to that. I know, I know -
>
the JNI and C dylibs should be one or at least packaged together and
>
we will do that in the next release.
Using JNI and/or a dylib is neither more nor less secure than writing two
Mach-O executable tools, the first of which makes the Authenticate-dialog
calls to obtain the right from the Security framework, and the second of
which is the privileged helper-tool executed with euid of root.
The advantage of using Runtime.exec() to execute the first process is that
it requires no JNI-lib and no 'native' methods in the applet. A
native-code file is still be written, and ative code is still being
executed, and an Authenticate dialog is still being presented, it's just a
different execution pathway that doesn't involve JNI.
The trustworthiness and security of this approach is essentially identical
to having a signed applet install a temporary JNI-lib, dylib, and
privileged helper tool.
Depending on what the privileged helper tool needs to do, the preinstalled
command /usr/libexec/authopen may be good enough, and the first executable
or JNI/dylib might not be necessary at all. See 'man authopen' or type
'/usr/libexec/authopen -h' for a summary. The authopen command is present
at least as far back as 10.1.
-- GG
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/java-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
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.