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.
OK, the problem with touching on the subject in mail list posts. You
can't completely cover the topic and about all I could do was guess
the reason for a point you were stressing.
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.
Already agreed.
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.
I don't know I haven't tried them. Again basically I make my
assumptions on JAAS - Java Authentication and Authorization Service.
I look for it to provide interfaces that authenticate me as allowed
to and authorize me to actually do something.
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.
I think here you are maybe you are skipping back and forth in
replying to both me and Dmitry? Anyhow I gave my issues with the
UnixLoginModule earlier. Whether these are a necessary problem due to
the Unix/Posix model I don't know, but it seems for both me and
Dmitry it wasn't of a lot of use.
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 ); }
True boiled down this is about all I did except within the JAAS API
interface and with the property kludge.
I'm not sure about the point you are making as to the side-effect.
The property is pretty much equivalent to the command line usage you
came up with for testing. If you authenticate correctly do the
current action using the authkit code for the authorization and
invocation needed. The AA is there but coming from authkit. My
understanding is its sort of like sudo in running admin with a 5
minute limit. I didn't test extensively though so I don't know how it
works for repeated iterations or for how long. I was taking it
basically as a one-shot action requiring admin.
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.
If anyone wanted to use what I did for authkit and jaas or come up
with something of their own for authkit and jaas they might want to
make it more atomic and again more like a one-shot by _always_
tearing things down when done. This would make it less likely someone
might change the property and run their own action as admin.
But again I'm not seeing how my approach is less secure than directly
using the authkit API's. The authentication dialog should protect
both. If there is a 5 minute sudo type exposure it is there for both.
_______________________________________________
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
