Re: [stellation-res] Command line configuration specification

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Mon, 2003-01-13 at 15:23, Jonathan Gossage wrote:
> ----- Original Message -----
> From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
> To: "Stellation-res" <stellation-res@xxxxxxxxxxxxxxx>
> Sent: Monday, January 13, 2003 3:07 PM
> Subject: Re: [stellation-res] Command line configuration specification
> 
> 
> > On Mon, 2003-01-13 at 14:42, Jonathan Gossage wrote:
> > > > - I'm pretty sure that MySQL has a notion of a database name, and so
> > > >   there should be an option to specify that.
> > >
> > > If I remember correctly, this is managed within the Mysql configuration
> > > files and is not exposed to the JDBC driver, but I will double check
> this.
> >
> > I can't find my MySQL manual right now (it must be at home)... But I
> > thought you could create more than one database, and expose all of
> > them to JDBC. I think there is a default database, which is what
> > you get connected to when you don't specify a dbname, but I'm pretty
> > sure there's also a way to connect to other DBs.
> >
> > > > - In the Server-connect element of the config file: the intention is
> > > >   to have a server listen on a single port: the login and subscription
> > > >   process is how we distinguish a child server from a client. So there
> > > >   shouldn't be a distinct port for accepting connections from
> children.
> > >
> > > Is there any specs on this yet?
> >
> > No, not yet. The basic concepts are described in some of the papers, but
> > the details have never been set down.
> >
> >
> > > > - I'm a bit skeptical about encrypting the database admin password.
> The
> > > >   question is, how do we encrypt it? I can't think of a way that won't
> > > >   be easy to reverse engineer and determine the password. (For
> example,
> > > >   we could hardcode a password when we compile the server, but then
> that
> > > >   password can be found by looking at the .class file. We could
> encrypt
> > > >   that, but then it's still not too hard to find a way to figure out
> how
> > > >   we did that, and get *that* password. It seems to me that
> ultimately,
> > > >   unless we require the administrator to specify a password when they
> > > >   start the server (which precludes automatically starting servers),
> > > >   then we are ultimately relying on the fact that the config file is
> > > >   secured. Putting the encryption in is giving people a false sense of
> > > >   security that they don't really need to be so careful of protecting
> > > >   their server config file.
> > >
> > > It only provides light security. All it can do is prevent browsing
> > > plain-text files to prevent casual snooping. In general it is not
> possible
> > > to provide any serious security in environments where debuggers or other
> > > observational tools can be run. That being said, 90% of attempts to
> crack
> > > security can be stopped by simple measures such as not leaving
> plain-text
> > > passwords lying around.
> >
> > And even more by using appropriate file protection, so that people
> > can't snoop the files without already having compromised your system
> > so badly that nothing is safe anyway.
> >
> > Sorry, it's the unix snob in me;
> > I always forget that the majority of users out there are using a system
> > where file access security doesn't really work. In Linux, you just put
> > config files like that in a directory that users can't access. For
> > example, using root privs, I can figure out the passwords for encrypting
> > the password table in postgres in about five minutes. A user without
> > root privileges simply can't get to the files that they would need to
> > see to do it.
> 
> Also remember that the one of the greatest vulnerabilities is disaffected
> sysadmin types and there are known, published ways of making yourself root .

As I said above: "... without already having compromised your system so
badly that nothing is safe anyway.". Once you've let someone get
into your system with a root exploit, pretty much everything is out
the window, and nothing that we're going to do in Stellation is going to
reduce the potential damage.  

(You can go, in theory, go all out, like OpenCM, which
encrypts *everything*, and requires the admin to access the repository
with a secured private key; even with root privs, you can't even get a
list of projects out of the repository.  You can delete the repository,
but you can't modify its contents. But I don't think any of us want
to go that route.)

All I really meant to say was that I want us to be really clear
about how much security we can offer, and what you have to do
to achieve that level of security. Encrypting that password is
fine; I just also want us to be clear that if you really want any
security out of your repository, then you shouldn't rely just on
the encryption of the admin password: securing the configuration
and the database are also critical.

If we're going this route, I'd also like to use the same mechanism
that we use to encrypt the admin password in the config
file to encrypt the passwords in the database. Right now, the
password field in the database is wide open plaintext, and I've
been wanting to put in a fix for that. We might as well use the
same mechanism for both, since once you've got the admin password,
you've effectively got all the others anyway.

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxxxxxx