(tye)Re: Question of safe data passing...

That is why I was thinking of a set-UID script/program that does nothing but get the secured password, run your script, and pass the password to it over a pipe.

You aren't going to get security without set-UID as that is really the only way to stop the current user from being able to do exactly what you do in order to find the password.

But you can isolate the set-UID to just a separate script/program that does nothing but what I outlined and is very careful including removing any privileges before it runs the specified script (which is specified in the same secured location as the DBI password).

- tye (but my friends call me "Tye")

Comment on (tye)Re: Question of safe data passing...

Replies are listed 'Best First'.
Re: (tye)Re: Question of safe data passing... by suaveant (Parson) on Apr 27, 2001 at 21:38 UTC
Yes, that's about what I've concluded from this thread... I had thought of that as a possible option... basically write a C wrapper that calls setuid in the middle does its important stuff like opening a file, then drops back to normal mode and runs a system call, passing the data through a pipe seems proper, though I'm not sure how to do that, I'm sure I can figured it out with enough headbanging, (C was the main language in school, but I don't use it much anymore :) anymore). - Ant	[reply]
(tye)Re2: Question of safe data passing... by tye (Sage) on Apr 28, 2001 at 00:17 UTC
I'd actually handle this using sudo or something similar to launch a Perl script with taint checking turned on since C doesn't provide a taint checking mechanism (you could use a set-UID Perl script or a setuidperl executable but I think that sudo is more secure -- though I'm not completely up-to-date on this). Then the script starts with both UIDs, you use the effective UID to get the protected password and which script to pass it to, then you remove all trace of the privileged UID (this is a bit tricky) and launch the new script with a pipe open to it. You can also protect the source code of the privileged script which means you can encrypt the protected password so that both the protected configuration file and the protected script would have to be compromised (and the culprit use the algorythm and key in the script to decrypt the password) for the password to be compromised. - tye (but my friends call me "Tye")	[reply]