hansen@pegasus.UUCP (Tony L. Hansen) (09/13/85)
I was recently asked what the implications would be of having the shell do a setuid(getuid()) and setgid(getgid()) as soon as it's invoked. The reason is to try and plug up any security holes caused by set[ug]id programs that invoke system(3C) or popen(3S). What tools are there that anyone knows of that would be broken if this change were made, locally, or for real? Tony Hansen ihnp4!pegasus!hansen
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/17/85)
> I was recently asked what the implications would be of having the shell do a > setuid(getuid()) and setgid(getgid()) as soon as it's invoked. The reason is > to try and plug up any security holes caused by set[ug]id programs that > invoke system(3C) or popen(3S). What tools are there that anyone knows of > that would be broken if this change were made, locally, or for real? cpio, find, & sdiff all use popen() and tar uses system(). Your proposed change could break their operation when these utilities are run privileged. There are many other loopholes of equal or greater concern than "sh -c" that your shell mod would not take care of. This seems like the wrong place to try to enforce security.
mike@whuxl.UUCP (BALDWIN) (09/18/85)
[ what would break if /bin/sh did setuid(getuid()), setgid(getgid())? ] > Well, shell scripts invoked by someone who was su'ed to someone else could > fail, couldn't they, in this situation? (The resulting spawned shells would > not have the proper uid and gid.) Nope, because su(1) sets both the effective *and* the real [ug]id. The only way to run the shell with real != effective is to exec it from a set[ug]id C program (e.g., system(3C) or popen(3S)) or use #!/bin/sh in BSD (but it's *real* easy to break set[ug]id #!/bin/sh files). -- Michael Baldwin AT&T Bell Labs {at&t}!whuxl!mike
mike@whuxl.UUCP (BALDWIN) (09/19/85)
> > I was recently asked what the implications would be of having the shell do a > > setuid(getuid()) and setgid(getgid()) as soon as it's invoked. The reason is > > to try and plug up any security holes caused by set[ug]id programs that > > invoke system(3C) or popen(3S). What tools are there that anyone knows of > > that would be broken if this change were made, locally, or for real? > > cpio, find, & sdiff all use popen() and tar uses system(). > Your proposed change could break their operation when these > utilities are run privileged. There are many other loopholes > of equal or greater concern than "sh -c" that your shell > mod would not take care of. This seems like the wrong place > to try to enforce security. Nope: cpio, find, sdiff and tar aren't setuid or setgid, so it doesn't affect them at all. It *only* affects setuid or setgid C programs that exec the shell either directly, or through system() or popen(). This loophole is quite large, why not fix it along with the others? -- Michael Baldwin AT&T Bell Labs {at&t}!whuxl!mike