perl MySQL using DBI - security issue

[John]

Hi

When using MySql with Perl and useBI you need to supply username, password
and database.

My question is this.

What is now considered the *best* method to prevent those three variables
being accessed by outsiders?

Running on a Linux server.

Regards
John

 

[crumbs.j]

By outsiders are you thinking of 1. hackers or 2. people browsing your
directory who work in your company or do you mean from 3. the web?

1. If a hacker gets into your comp, he is coming in as root and it
doesnt matter what you do.

2. If it is someone else in your company you can stick the data in a
prop file and use unix security [ chmod 400 <propfile> ]

3. If you are running CGI based webapps, after your DB processing is
connected and done nothing should be displayed [ I hope ]

Now if you want to really get crazy, use the crypt() function to write
out the info to a file and decrypt() to access it from inside your
script

-C
Internal Kit Kat Contest
http://www.iamfood.com/contest

 

[Matt Garrish]

news:[email protected]...

[attribution and tofu corrected]

Now if you want to really get crazy, use the crypt() function to write
out the info to a file and decrypt() to access it from inside your
script

Which is really silly, too. I did that once with the note "if you got this
far, I'm sure you can figure out the rest". If they can access your script
source (and presumably the filesystem), it would take only a few seconds to
modify the script to output the decrypted username/password. As you're
alluding to, however, the best defence is to not let them in in the first
place.

<att

 

[Matthew Braid]

Not sure if it's the best way, but the way I do it is to have that data
stored in a config file that is owned by a dummy user and only readable
by that user. I then have a package that reads this data on load into
my'd variables (so even a subclass can't see them), and internally
handles the connections. So instead of using the normal DBI connection
method, you instead do something like:

$db_handle = LockedDBPackage->connect;

All programs that need the database then have to be setuid that dummy
user and then use the database package, 'drop' privs and then exit if
privs can be regained.

Problems then become:

* Taint mode is automatically on. Yeah sure its more secure, but
you'd be amazed the number of packages out there that completely bork on
the weirdest of things when taint is on. Case in point - perl/Tk's
get[Open|Save]File dialog box will not work, and you can't even
_display_ tainted text in a textbox. Usually its possible to work around
this, but in places where it isn't the Taint::Runtime module is
surprisingly handy (assuming of course you use it judiciously and don't
just turn off tainting alltogether, which I wouldn't recommend).

* While the password can't be directly accessed, should a user cause
the program to core dump they can get at it. You can add SIG traps to
stop core dumping, but that's assuming your users are just using
programs and not using libraries for their own programs.

* Allowing people to use these your DB-based code as libraries now
requires you (or whoever is in control) to vett the code since
(hopefully!) your users can't setuid their scripts to the dummy user.
This is actually probably a good thing, but slows development.

Hope this helped.
MB

 

[Daud Lee Lambert]

Hi

When using MySql with Perl and useBI you need to supply username, password
and database.

My question is this.

What is now considered the *best* method to prevent those three variables
being accessed by outsiders?

Running on a Linux server.

If you're using MySQL for a webserver and control everything on that
webserver, don't bother with a password; just use host-based
access-control. I do that when I write sample CGI programs on my laptop.

If you're writing CGI code that goes on some sort of shared-hosting service,
all you can do is make sure that your source-code is never accessible from
outside or readable by other users. Don't stick the pssword in a ".txt"
file; put it at the top of each '.cgi" file, or in a common "include.cgi"
or whatever.

If you're writing little scripts to work on a user-authenticated database,
just "chmod 400" your source-code. If you're worried about people
shoulder-surfing while you write your programs, set the password in
"~/.my.cnf" (remember: "chmod 400") and use code like the following:

open MY_CNF, $ENV{HOME}.'/.my.cnf';
while (<MY_CNF>) {
$dbuser = $1 if /^user=(\S+)/;
$dbpass = $1 if /^password=(\S*)/;
};
die if (!defined($dbuser) or !defined($dbpass));

I wish DBD::MySQL had an easier way to use the "default connect info" from
the comand-line, environment variables, /etc/my.cnf and .my.cnf, but AFAIK
it doesn't (yet)..

 

[DJ Stunks]

If you're writing little scripts to work on a user-authenticated database,
just "chmod 400" your source-code. If you're worried about people
shoulder-surfing while you write your programs, set the password in
"~/.my.cnf" (remember: "chmod 400") and use code like the following:

open MY_CNF, $ENV{HOME}.'/.my.cnf';
while (<MY_CNF>) {
$dbuser = $1 if /^user=(\S+)/;
$dbpass = $1 if /^password=(\S*)/;
};
die if (!defined($dbuser) or !defined($dbpass));

I wish DBD::MySQL had an easier way to use the "default connect info" from
the comand-line, environment variables, /etc/my.cnf and .my.cnf, but AFAIK
it doesn't (yet)..

Not a bad idea, also makes for more portable code -- you don't need to
specify username in every script that connects to the database. Change
your DB password and you only have to edit one file.

But rather that parsing my.cnf on your own, let me suggest (from a
quick CPAN search):
http://search.cpan.org/~darren/MySQL-Config-1.03/lib/MySQL/Config.pm

-jp

 

[Peter J. Holzer]

By outsiders are you thinking of 1. hackers or 2. people browsing your
directory who work in your company or do you mean from 3. the web?

1. If a hacker gets into your comp, he is coming in as root and it
doesnt matter what you do.

Not necessarily. In fact a big part of making systems "secure" is
ensuring that the hacker is not coming in as root, but as a user with as
little privileges as possible.

hp