On Fri, Jan 02, 2004 at 12:26:10AM +0200, Antti-Juhani Kaijanaho wrote: > Hi, (...) > My plan of action is to add support for "file names" that are passed to > /bin/sh as commands, whose standard output stream becomes the default > input. Now, since this will involve allowing execution of arbitrary > "out of band" code, I am concerned that I may introduce a security > problem. For example, if /etc/grep-dctrlrc or ~root/.grep-dctrl.rc > becomes world-writable for some reason (it isn't by design, of course), > a malicious local user can add code that will be executed as root when > root next runs grep-available. > > In your opinion, is there any potential for a security problem in this > scheme? If there is, what should I do about it? I don't fully understand your design, however, if you are going to use configuration files that might be tampered by a user to run external commands it might be worthwhile to check their permissions and ownership before making use of them (i.e. ensuring they are not world-writable and that they belong to the current runing user). It is very common, however, to use configuration files in a way that they can modify the way code is executed. For example: a- obviously, stuff like ~/.bash_aliases b- init.d scripts sourcing /etc/default stuff and using options it as "addendum" to those used in the script to startup/stop things. Some programs really do not care who the configuration file belong to, other (sensitive) programs do check file permissions (ssh and gpg come to mind). http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/file-contents.html HTH Javi
Attachment:
signature.asc
Description: Digital signature