store password in a module ?

[Qiang]

hello,

i have a module connect to a database and return some information for
user. the database name and password are stored in it.

now the user will run another perl file which use the module. however,
i don't know how do i pretect the database password from user?

i heard about setuid, but it seems to have it's own security problem.

can anyone recommend elegant way to solve this problem ?


thanks !


James.Q.L

 

[Brian McCauley]

i have a module connect to a database and return some information for
user. the database name and password are stored in it.

now the user will run another perl file which use the module. however,
i don't know how do i pretect the database password from user?

Aggghhhhh! Didn't we have this thread already this week.

i heard about setuid, but it seems to have it's own security problem.

can anyone recommend elegant way to solve this problem ?

This is the perpetual motion machine of computer programming.
It has very little to do with the specific lanuage.

You cannot do this with a module or library that loads into the
user-space of your program. Some operating systems (eg VMS) have a
concept of a priviledged library that you can call rather like an OS
call. (IIRC Solaris has something called "doors" which may apply).

In general the only way to do it is a helper process. The helper
process runs under a different UID an accepts connections from clients
(using a UNIX domain socket or whatever) and forwards them to the
database.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[Malcolm Dew-Jones]

Qiang ([email protected]) wrote:
: hello,

: i have a module connect to a database and return some information for
: user. the database name and password are stored in it.

: now the user will run another perl file which use the module. however,
: i don't know how do i pretect the database password from user?

: i heard about setuid, but it seems to have it's own security problem.

setuid to root is a security problem, setuid to some other non-priv
user is not inherently a problem.

: can anyone recommend elegant way to solve this problem ?

Set the file containing the password to be owned by a non-priv user set up
for this task. Do not allow any user other than the owner (which is a
dummy account) to read that password file.

Set the script that reads the password to be suid to that non-priv user.
The script can now read the password, but a user running the script
cannot, by themselves, read the password.

You must now make sure that the script is secure, in the sense that only
the appropriate people can run it, and that when they run it they can only
use it for the purpose for which it is intended.


Control who can run the script however you wish, depending on the
circumstances. One technique is for the script to be group
read/executable, and owned by a group set up for this purpose. Users who
should be able to run the script are placed in that group.

The script itself must control how it is used. I think taint mode is
turned on by default in this situation, but in any case it should be,
which helps to ensure the script has no holes, and of course the script
must not do anything such as allow a user to access the command line via
the script, or to allow them to access the inner variables of the script.
(Does taint turn of debugging? I have never thought about it, but I hope
it does.)

 

[Sam Holden]

On 26 Nov 2003 15:13:25 -0800,

[snip suid script discussion]

(Does taint turn of debugging? I have never thought about it, but I hope
it does.)

Of course not, using taint checking doesn't magically produce bug free
code - hence debugging is still sometimes necessary. And not being able to
use the debugger would be a pain for those who like it.

Of course you can't pass arbitrary command line arguments to the suid perl
due to the way #! works. And you can't modify the script and still have it
be suid (unless you already have access anyway), so there is no need
to disable it in the presence of taint checking.

 

[Ben Morrow]

Qiang ([email protected]) wrote:
: i heard about setuid, but it seems to have it's own security problem.

setuid to root is a security problem, setuid to some other non-priv
user is not inherently a problem.

Not true. Obviously the user you are setuid-ing to can do something to
user you are setuid-ing from could not, otherwise there would be no
point. Hence, you have a potential security problem.

: can anyone recommend elegant way to solve this problem ?

Set the file containing the password to be owned by a non-priv user set up
for this task. Do not allow any user other than the owner (which is a
dummy account) to read that password file.

This is the right answer, yes.

Ben

--
Heracles: (e-mail address removed)
Vulture! Here's a titbit for you / A few dried molecules of the gall
From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
(Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ]
/Alcestis/) [ flame, and falls out of sight. ]

 

[Malcolm Dew-Jones]

Sam Holden ([email protected]) wrote:
: On 26 Nov 2003 15:13:25 -0800,

: [snip suid script discussion]

: > (Does taint turn of debugging? I have never thought about it, but I hope
: > it does.)

: Of course not, using taint checking doesn't magically produce bug free
: code - hence debugging is still sometimes necessary. And not being able to
: use the debugger would be a pain for those who like it.

: Of course you can't pass arbitrary command line arguments to the suid perl
: due to the way #! works. And you can't modify the script and still have it
: be suid (unless you already have access anyway), so there is no need
: to disable it in the presence of taint checking.

That all makes sense.

Just as long as a normal user cannot run the suid program, and become the
suid user, and then also use the debugger to examine (or modify!) the
value of the variables of the program, which in this case is what must be
protected.

In any case, the user must figure out any possible interactions that the
suid program could allow that would allow the password to be learnt. One
of my first thoughts is to try to break the protection using the debugger
by examining the variable. I would not want to allow command line access
to the perl suid program in this case (where it is protecting data)
until I had convinced myself (among other things) that I understood the
interactions of the suid and the debugger well enough to know it was not a
problem, or if it was a problem then to know how to prevent the use of the
debugger in this situation.

I haven't had to do this, so I do not know for sure if there is/was an
issue, therefore I mentioned it.

 

[Qiang]

Aggghhhhh! Didn't we have this thread already this week.

just read it. but surprisingly there is not even a solution offerered
but tone of discussion of why security by obscurity is bad.

This is the perpetual motion machine of computer programming.
It has very little to do with the specific lanuage.

You cannot do this with a module or library that loads into the
user-space of your program. Some operating systems (eg VMS) have a
concept of a priviledged library that you can call rather like an OS
call. (IIRC Solaris has something called "doors" which may apply).

In general the only way to do it is a helper process. The helper
process runs under a different UID an accepts connections from clients
(using a UNIX domain socket or whatever) and forwards them to the
database.

sorry, i don't quite sure how to achieve that and why that will work.
guess i really need to read a tutorial or more to understand how to do
it.

anyone have a nice link for this kind of problem?


James.

 

[ctcgag]

hello,

i have a module connect to a database and return some information for
user. the database name and password are stored in it.

now the user will run another perl file which use the module. however,
i don't know how do i pretect the database password from user?

Make a database account that only has the priviledge to get the information
(not to change it or do anything else you don't want the user to do).
Then make the module use that account, and who cares if they can get its
password? Sometimes that is easier said than done, but I think it's the
best solution.

i heard about setuid, but it seems to have it's own security problem.

can anyone recommend elegant way to solve this problem ?

I think it would pretty elegant if there were a variant of "use", let's
call it "abuse", which instead of loading and compiling the abused module
into the original executing interpreter, would instead fire up a setuid
interpreter for the module, acting as a server, and connect the abusing
module to it as a client. Then it would do all the necessary shenanigans
to make it (mostly) transparent.

Xho

 

[Ben Morrow]

I think it would pretty elegant if there were a variant of "use", let's
call it "abuse", which instead of loading and compiling the abused module
into the original executing interpreter, would instead fire up a setuid
interpreter for the module, acting as a server, and connect the abusing
module to it as a client. Then it would do all the necessary shenanigans
to make it (mostly) transparent.

http://morrow.me.uk/Acme-Abuse-0.02.tar.gz

Quite a lot of emphasis on the 'mostly' .

Ben