I thought maybe you would be able to subsequently do stuff like
create low number port server sockets from the current admin
authorized process but that did not work either.
As I understand JAAS's security model, it runs within a single process
(JVM). It may have connections to other processes, such as in a
distributed J2EE model, but it doesn't have to. That makes JAAS a
fine-grained security model that grants or denies permission to
fine-grained elements (classes, class-loaders, and code-bases within a
single JVM process) for specific fine-grained actions, and also one
that
fundamentally differs from the Unix/Posix setuid security model.
In the Unix/Posix setuid model, there is no way to elevate the
privileges
(i.e. the uid) of an unprivileged process. This is intentional.
Instead,
it's necessary to spawn a new process that gains elevated
privileges, but
in doing so cannot return. From that elevated state executing a new
program, it can then modify or demote its own privileges, either
temporarily or permanently. The values are heritable and coarse-
grained.
The privileges implied by a uid or gid apply for the ENTIRE
process, not
just for fine-grained elements within the process, such as classes,
class-loaders, and code-bases. If you call setuid() or seteuid()
in ANY
thread, then EVERY thread in that process gains or loses whatever
privileges are implied by the resulting uid, regardless of what any of
those threads are doing at the time. That model is fundamentally
different
from JAAS's model.
Fine, except I'm not sure what security advantage there is to being
able to create and communicate with a privileged process rather than
become one yourself. Except possibly it's somewhat better in
encapsulation of the risk exposure. However, I'm not that
knowledgeable on the Unix/Posix security model and this thread is
probably not the place to correct that.
By the way, the UnixLoginModule (or more precisely, the UnixSystem
class
which it calls) uses real-uid and real-gid to determine access
permissions,
while the OS itself actually uses effective-uid to determine access
permission. As a result, there's a mismatch in perception when
Java is
running as setuid-root, because the process will have euid of root but
real-uid of your login uid. So the process may well have god-like
powers,
but UnixLoginModule would still only perceive the login real-uid.
The problem I had with the UnixLoginModule was not that it didn't
allow the access I wanted but that it didn't do real authentication,
I thought the purpose of JAAS. At least it didn't allow
authentication in testing. In running the code as I was already a
valid logged on user there was no way it appeared to ever indicate I
wasn't one. It ignored bad or no passwords. Not much use since the
authentication that I was a valid although not necessarily the
current user was what I was looking for. No change in access needed,
just did I know a user/password at all.
This is easy to demonstrate by making a copy of the 'java'
executable in
the JavaVM.framework, changing its mode to setuid, its owner to
root, then
running it. The process will have an euid of root, but a real-uid
of your
login, so the Java code can read or write anything anywhere, leap tall
buildings in a single bound, etc., but UnixLoginModule still thinks
you're
just your meek and mild-mannered everyday self.
The privileged child process spawned by execPrivileged() is in
exactly the
same boat, because it runs with euid of root and original login for
real-uid.
I'm not quite sure I'm following the distinction here again. Which
might be important to Dmitry's original post. Are you saying that
despite providing proof by dialog that you are or know a admin user/
password that you may not be able to do what you want? Or what are
you saying here?
Basically since what Dmitry was originally looking for was a JAAS
login module that allowed what he wanted I thought coming up with one
as a front-end API to yours might be a good fit. Originally, yes I
thought after running it I would be able to Runtime admin based code.
However, even with the property kludge to provide what is to be run
privileged it might not make a bad standard java API front-end thats
not really all that different from how you designed your code to be
tested. If more than one thing needs to be done you can provide a
delimited string that can be split into an array the same
as your code does...
System.setProperty("authkit.action","command1 : command2 : command3");
although I didn't add anything to support the delimiter.
What exactly Dmitry wanted to do requiring admin wasn't completely
clear so for that reason this approach might be off the mark. But
basically it is your code just interfaced through JAAS with the
property kludge.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
