Lloyd, can you forward this message to the appropriate ARC alias
and Cc me, or tell me where to send it? Thanks.
I've implemented the technique described. I'd like to get someone
to review the security aspects of the implementation as well as the
server integration aspects of the implementation.
Any volunteers?
Lloyd Chambers wrote on 8/4/09 11:30 AM:
> Sounds like a novel approach, and seems reasonable on the face of it.
>
> But as a novel security approach, definitely we should bring this up at
> ARC.
>
> Lloyd
>
> On Aug 3, 2009, at 5:35 PM, Bill Shannon wrote:
>
>> Currently in v3 the asadmin stop-domain command fails if the domain
>> has a non-default admin user and you don't specify the user name.
>> In v2 stop-domain would succeed in this case, as long as you were
>> on the same machine as the DAS.
>>
>> The v3 stop-domain command needs to execute the command on the server
>> (as opposed to using "kill" or something like that), which means it
>> needs to authenticate with the server. To allow v3 to be more compatible
>> with v2, we're considering adding a new authentication mechanism that
>> will "only" work in the local case.
>>
>> Roughly, here's how this would work...
>>
>> On server startup, the server would generate a large random number
>> and write it in a file that is readable only by the owner of the
>> file (the user who started the server).
>>
>> Local commands, such as stop-domain, would read this file if it's
>> available and send the number as part of the authentication information
>> to the server. The server would accept either the normal
>> username/password
>> authentication, or some special username along with this number as the
>> password.
>>
>> This allows anyone who can read the file to authenticate to the server.
>> Normally this would only be the user who owns the server and is running
>> on the same machine.
>>
>> First, see any holes with this approach?
>>
>> Second, should we generalize this approach and allow it to be used
>> for normally remote commands as well? This means you could create a
>> domain with a non-default admin user and in the local case you would
>> never need to specify the admin user name or password, and yet there
>> would be some protection against remote admin access.
>
> Lloyd Chambers
> lloyd.chambers_at_sun.com
> GlassFish Team
>
>
>