Michael Hall wrote:
>OK, I got back to reading this and I'm sorry but clear as it is it is
>still not explained well enough for me to completely understand the
>whys and where for's - but thats OK. I would guess the original uid
>is kept as a possible later audit trail as to what mischief was
>actually done with the admin access? But that would still be a guess.
Your guess is incorrect. It has nothing to do with audit trails.
I didn't intend my earlier explanation as a complete tutorial, but as a
reminder in case one had forgotten the details. But if one didn't know the
details at all, then it would likely still come across as obscure technical
gobbledigook.
The best way to understand the purpose of effective and real uids is to
read a tutorial or reference that explains them and how they relate to the
overall Unix/Posix security model. For that, I suggest googling for terms
like 'unix effective uid tutorial'. The whole thing works as a system with
the setuid-bit of executable files in the file-system, so don't expect one
thing explained without the other.
There's also some brief explanation in the latter parts of 'man 2 intro'
and some additional brief info in 'man execve', on Mac OS X, via
Terminal.app. However, those are brief summaries, not full explanations.
I don't have a specific URL to point to that explains it all, because I
first learned the model in Unix v6 days of yore, when a 100 MB hard drive
was the size of a washing machine and 256 KB was considered huge tracts of
RAM. It's possible that either Kernighan or Ritchie wrote an article about
the Unix model (setuid was an early software patent; a marvel in its time),
so it wouldn't hurt to add those names to the googling keywords.
>But again I wasn't really trying to better grasp the details of Unix/
>Posix security.
I don't think I made my point clearly enough in my earlier posts. Without
an understanding of the Unix/Posix security model, in particular the
concepts of real and effective uid, and of setuid, you cannot hope to
understand or appreciate the limitations imposed by that model. In
particular, it is not possible to elevate the privilege of an unprivileged
process, and the reason that is so is due to the security model (effective
uid, real uid, and setuid). Conversely, it *IS* possible to relinquish
privilege from a privileged process, and again the reason that is so is due
to the security model.
In short, it seems to me that what you were trying to do with the JAAS
module is impossible under the Unix/Posix security model, and it's
impossible because the Unix/Posix model was designed to exclude it.
I should also point out that other security models, such as Kerberos, have
their own models, with their own restrictions and limitations. So if a
Krb5LoginModule didn't already exist, it would be silly to try to create it
if one didn't understand what the Kerberos security model was and how it
worked. Same thing goes for the NTLoginModule, or whatever security model
you care to base a LoginModule on.
>For my purposes, again just for the exercise, I wanted to see if I
>could come up with the JAAS login module I had myself suggested to
>Dmitry's first post. Partly because I had been unable previously to
>get UnixLoginModule to work at all and I wanted to see if I could
>have more success with my own. I did, although less than complete
>success as discussed.
I'm pretty sure the main reason for lack of success is precisely because
the JAAS model is not a match to the Unix/Posix model, and vice versa.
The hack you added, as the "authkit.action" property, simply established a
side-effect that was eventually triggered by successful JAAS login. You
could have accomplished the same thing more clearly by eliminating JAAS
entirely, and just simplifying and restricting the visible API that called
AuthKit. In other words, if all you want is a highly simplified API to run
as root, you can accomplish it without JAAS. Just create a class with this
public API:
public class UtterlySimple
{ public static int runAsRoot( String[] commandLine ); }
then implement the body of runAsRoot() using AuthKit. Simple and direct.
Or you could have obfuscated it in a completely different manner, such as
by creating a FilterOutputStream, a URLConnection, or a
CharToByteConverter. There are any number of places where one can attach a
latent side-effect to a Java component.
One advantage to an overt approach like UtterlySimple.runAsRoot() would be
that everything is explicit. There are no side-channels or side-effects,
such as a magic property with a particular command whose output may come
back on another side-channel (or not).
It seems like a bad idea to me to intentionally build a security apparatus
that performs possibly dangerous actions using side-channels and
side-effects arising from indirect actions. In general, one strives to
REMOVE side-channels and side-effects from security elements. It may be
informative or amusing, but as a practical strategy it seems ill-advised.
YMMV.
-- GG
_______________________________________________
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
