setuid ignores environment variables
param
LIBPATH, NLSPATH while linking/loading the libraries or using catalog
files. This is applicable to both dynamic linking with library or
loading using dlopen function. Is there a way to instruct the OS/
application to consider those variables with setuid?
Barry Margolin
<0e3f312f-1c7e-49ca...@o10g2000yqa.googlegroups.com>,
param <sparam...@gmail.com> wrote:
This would be a VERY BAD IDEA. It would allow the caller to execute any
code they want as the target user. For instance, with LD_LIBRARY_PATH
they could provide a version of exit() that performs the equivalent of
"rm *" in the target user's directory. And if it's a setuid-root
program, they could take down the entire system.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
param
> code they want as the target user. For instance, with LD_LIBRARY_PATH
> they could provide a version of exit() that performs the equivalent of
> "rm *" in the target user's directory. And if it's a setuid-root
> program, they could take down the entire system.
> --
its own libraries
in system directory[/usr/lib | /lib].
David Schwartz
Yes, but you have to actually write the code to do it. It can't be
done automatically because those environment variables would have to
be carefully sanitized to ensure they don't pose a threat to the
setuid program.
What you do is you write a program that you leave non-setuid that
assembles all the environment variables the setuid program needs and
puts them someplace it can get them. For example, you could put them
in a temporary file and pass the path of that file to the setuid
program. (The program can just write the whole environment to a file
with no processing, if desired.) The setuid program then runs, reads
in the temporary file, and selectively sets those environment
variables it chooses to honor.
It must check each setting carefully to ensure it doesn't pose a
security threat. Obviously, being able to replace libraries that a
setuid program runs is equivalent to being that user, since your
library could, for example, set an arbitrary program setuid if
maliciously constructed to do so.
If needed, the setuid program can then launch the actual desired
program, which would then not need to be setuid. In that case, the
environment settings passed to it by the setuid program would be
honored.
Note that is extremely advanced UNIX programming and should not be
attempted by those who don't deeply understand the consequences of
what they're doing. The three program approach is, IMO, best. Again
they are:
1) User helper program, not setuid. This program puts the environment
or other user settings where program 2 can find it.
2) The launcher program itself. This program is setuid and reads the
environment or whatever settings that program 1 placed for it, it sets
up the environment and security context for program 3. Note that this
program must carefully screen everything it passes to the third
program.
3) The program that does the actual work, which now does need to be
setuid since program 2 set up its context and permissions.
DS
Barry Margolin
<62f6aac8-692e-4f0a...@b36g2000prf.googlegroups.com>,
param <sparam...@gmail.com> wrote:
Or you can specify the location of libraries at compile/link time.
param
> Note that is extremely advanced UNIX programming and should not be
> attempted by those who don't deeply understand the consequences of
> what they're doing. The three program approach is, IMO, best. Again
> they are:
>
> 1) User helper program, not setuid. This program puts the environment
> or other user settings where program 2 can find it.
>
> 2) The launcher program itself. This program is setuid and reads the
> environment or whatever settings that program 1 placed for it, it sets
> up the environment and security context for program 3. Note that this
> program must carefully screen everything it passes to the third
> program.
>
> 3) The program that does the actual work, which now does need to be
> setuid since program 2 set up its context and permissions.
>
>
What I understand is, the system functions like dlopen ignores the
environment variables(LD_LIBRARY_PATH) when effective user id not
matches with real user id. As per your approach, the third program
must pass the value of the environment variables to functions like
dlopen[that means, absolute path of the library]. We can't use the
search functionality of those functions[Yes, it opens up the secure
threat to the system]. For dynamic linking, As mentioned by Barry
Margolin, we can hard code the location of the libraries while
compiling.