Re: Question of safe data passing...
by frankus (Priest) on Apr 27, 2001 at 17:22 UTC
|
Kerayzee....
Can you not put the data in a file and set the permissions on this?
Encrypt it if you must, really this seems like a helluva lotta work.
If it were me, I'd make the server robust, not the individual scripts.
Zigster and I know of a certain software house that stores,
the access details for an Oracle Database in the applications
.ini file. Of course there are security measures... I mean rot13 is adequate for a 100+ user insurance system... no?
--
Brother Frankus. | [reply] |
|
A perl script has to be readable by the user running it...
I am trying to devise a safe way to feed in protected data without
making the script suid.
- Ant
| [reply] |
Re: Question of safe data passing...
by turnstep (Parson) on Apr 27, 2001 at 17:52 UTC
|
As I've said before, use environment variables. Unless
your system is set up very strangely, they are not
available in /proc. Then it's simple enough to do
something like this:
my $username = $ENV{'LC_MONETARY'};
my $pass = $ENV{'FOOBAR'}';
That way, anyone else on the system can read your
script, but it does them no good unless they are logged
in to the account with the environment variables.
| [reply] [d/l] |
|
if the script is running as you, you can see the environ
file in /proc
- Ant
| [reply] |
Re: Question of safe data passing...
by Rhandom (Curate) on Apr 27, 2001 at 18:07 UTC
|
Only truly safe way:
- Print the http request headers to a log file.
- Tell the user to wait.
- You, sitting at console, read the log file.
- You, write the request to the server which prompts you for the username and password (which you type in).
- The server hands back the results in a log file.
- You cat back the results to the end user.
Fairly straight forward. Very secure.
Possible problems:
- Your hits per second will suck (until you get really fast).
- This is still susceptible to you being kidnapped and tortured for the password that is only in your head.
- Even if you are not kidnapped and beaten, you will die from exhaustion only hours after you IPO.
There might be another way, but to do it without suid... I'd love to see it (and use it).
my @a=qw(random brilliant braindead); print $a[rand(@a)]; | [reply] |
|
Please, could you put a large flashing sign saying this is
not a practical solution, just in case one of our point-haired
managers sees it.
I say this after jokingly saying backups would be a lot
faster if performed on /dev/null rather than /dev/rmt0 .
Yours last backed up in December 2001
Brother Frankus.
| [reply] |
|
What do you mean it's not practical? {grin}
my @a=qw(random brilliant braindead); print $a[rand(@a)];
| [reply] |
Re: Question of safe data passing...
by arturo (Vicar) on Apr 27, 2001 at 17:25 UTC
|
| [reply] |
|
I read hiding DBI passwords... it hides them, but nothing
protects the virtual user from being used by other people
(I know, I asked the author)... so you still get the scripts
access to the DB... anyway, it is not too much work
because I want to make a generic tool people can use... its
not just a one time shot. It can also be used for other data,
not just DBI passwords...
- Ant
| [reply] |
|
Okay write a request server as a daemon that the scripts can
ask for stuff from. If you want to make it bafflingly encrypted.
Store the data as encrypted and use several salts. Store the
data in the server in encrypted form and transmit it encrypted.
After you've done this compile the perl code for the server and
delete the history files, burn your notes..... kill the sys admins
for your site1
1. This isn't totally necessary, but if your gonna be thorough ;^)
--
Brother Frankus. | [reply] |
|
|
|
|
In that case would it not be use-full to use a tunnel to protect your data. Something like the C script you talked about opens an SSH tunnel to the localhost and throws the data in there, with perl script waiting on the other side waiting to munge... ??? 8-&
Sinister greetings.
| [reply] |
|
|
|
Re: Question of safe data passing...
by lindex (Friar) on Apr 27, 2001 at 19:01 UTC
|
Aright how bout writing a perl script that creates a DBI object for you and freezes it using Storable, but before
it does this it reads a config file and looks to make sure the calling script and calling user are ok, if these conditions are met it then returns
the freezed DBI object to STDOUT easly read in and thaw'ed by the calling script
Of course the perl script would have to be compiled and the binary outputed would have to be chmod'ed with no read access, as well as suid so that it could read the "root only read" config file.
lindex
/****************************/
jason@gost.net, wh@ckz.org
http://jason.gost.net
/*****************************/
| [reply] [d/l] |
|
On to something here...
Instead of just storing the DBI object, make a DBI wrapper object that every time you try any method it checks to see if $0 still matches the copy that it stored in itself somewhere. If it doesn't match then it dies out. This way, you wouldn't be able to spoof the script your running on.
Er... uh.. will Storable cache a DBI object and allow you to reconnect at a later point?
my @a=qw(random brilliant braindead); print $a[rand(@a)];
| [reply] |
|
Ahh, can't use $0 because then you could just exec the DSN wrapper with the name of a valid script and BAM you have the "frozen" DBI object.
The DSN wrapper must find the name of its caller on its own.
And it must get this information from none user corruptable data. So the idea of passing the DSN wrapper a pid and then have the wrapper check proc to make sure the pid matches a allowable script name is also out of the question.
lindex
/****************************/
jason@gost.net, wh@ckz.org
http://jason.gost.net
/*****************************/
| [reply] [d/l] |
Re: Question of safe data passing...
by traveler (Parson) on Apr 27, 2001 at 19:21 UTC
|
To answer your direct question, how about just creating a pipe in the C code and writing the data on that, then reading it from the perl script?
Another general approach I have seen taken to this problem is to store the (strongly encrypted) password in a file readable only by user x and then have the progrem accessing the password run setuid x to access the file.
traveler | [reply] |
|
| [reply] |
Re: Question of safe data passing...
by lindex (Friar) on Apr 27, 2001 at 21:14 UTC
|
| [reply] [d/l] |