Lloyd Chambers wrote: > Bill Shannon requests some ARC feedback from those knowledgeable about > security on a new GlassFish 'asadmin' command line feature. Thank you > for any help you can offer. > > "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? > > .............. > BILL's PROPOSAL > > 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?
It seems reasonable enough. This is exactly the method I've seen used by the gallery PHP based photo hosting service. > 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. Maybe. -- Darren J Moffat
