Re: [stellation-res] Command line configuration specification

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- 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 .

>
> I don't object strongly to encrypting the password; I'll just insist on
> making the docs very clear that the encryption of the password is
> sufficiently weak that it should not be considered sufficient security
> unless the file is also protected.
>
> -Mark
>

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx