fixing the rwx--x--x problem

Roger Espel Llima (espel@llaic.u-clermont1.fr)
Wed, 16 Sep 1998 19:45:55 +0200

pacman wrote:
> Well, I just looked it over, and all it does to detect setuid is compare
> getuid() against geteuid() (And likewise for gid). That does serve to
> illustrate a flaw in my theory. set-id doesn't just disable LD_* in the
> immediately exec'ed program, it disables it in all further exec's within the
> same process and its children. Applying that same rule to --x exec's would be
> overkill. [...]
>
> Anyway, back to my point. Since there doesn't seem to be an easy way for
> ld-linux.so to know whether the main executable is readable or not, the only
> safe alternative right now seems to be, if you're going to use --x programs,
> link them statically (and for the sake of dlopen, unset LD_* first thing in
> main().) This is a very un-graceful workaround. If /proc/self/exe behaved as
> I had expected it to, it would all be so simple...

how about using the OpenBSD approach.. a flag in the task struct that
remembers if the program is "suid", and having ld.so check that instead
of checking various uid's, via a system call (issetugid() or something
like that).

then various libc functions can use that to decide whether they should
honor some environment variables that change the way some functions
behave.

to fix the rwx--x--x problem, issetugid() could be made to return
various flags, like

#define ISSETUID 1
#define ISSETGID 2
#define EXECNOREAD 4

ld.so could treat non-readable executables like suid ones, disallowing
LD_*.

and on exec the kernel could mask out the EXECNOREAD flag, so that the
rwx--x--x restrictions don't apply after an exec.

-- 
Roger Espel Llima, espel@llaic.u-clermont1.fr
http://www.eleves.ens.fr:8080/home/espel/index.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/