[MPlayer-users] vidix without being root or suid bit?

[D Richard Felker III]

On Wed, Sep 18, 2002 at 09:35:18AM +0200, Alessandro Selli wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Il giorno Tue, 17 Sep 2002, D Richard Felker III così ha scritto:
> 
> |From: D Richard Felker III <dalias at aerifal.cx>
> |To: mplayer-users at mplayerhq.hu
> |Date: Tue, 17 Sep 2002 18:13:58 -0400
> |Subject: Re: [MPlayer-users] vidix without being root or suid bit?
> |
> |That is nonsense.
> 
>   Do you mean something I wrote is wrong?
> 
> | If you run the suid-root mplayer with
> |/lib/ld-linux.so.2 /path/to/mplayer, the suid bit will ***NOT*** be
> |honored, since you are exec'ing /lib/ld-linux.so.2 (which is not suid)
> |as opposed to /path/to/mplayer (which is).
> 
>   I did not imply this would happen.  Mine was a generic warning against the
> false sense of security of simply setting an executable "noexec" to some
> users.  They should also be made non readable to those users.

Preventing execution is nonsense unless the binary is suid. Otherwise
the user can just install their own and run it...unless you're talking
about some sort of locked down system where users cannot write to any
non-noexec filesystems, but still it's possible to run arbitrary code
as yourself with some tricks, unless the system is totally crippled.
For example, your ld-linux.so trick will do it.

> |Of course if the binary is not suid (as in your example) it's even
> |stupider, since someone who wants to run it can just make their own
> |copy with cp and then run it.
> |
> 
>   I did not have the time to test that method of executing binaries
> thoroughly, I do want to find out if what you're writing is accurate.  When I
> execute suid binaries, what executes them is my shell, right?  My shell is
> not set uid root, right?  However, suid root binaries are executed with root

No, the shell forks and then calls exec* syscalls. The kernel then
looks at the binary whose name you passed to the exec syscall, and if
you have permission to run it, it replaces the current process's
address space with stuff to prepare for running the new binary. Also,
if the suid bit is set, the kernel sets the euid of the process to
match the file's owner.

Now, if you have a dynamic linked efl binary, part of the kernel elf
binary loader's job is to load /lib/ld-linux.so.2 (or whatever dynamic
loader is specified in the binary's elf headers) and use it to perform
the dynamic linking. If the kernel granted the process elevated
privileges (suid flag), then the dynamic loaded and the code it's
loading will have these privileges.

Running "/lib/ld-linux.so.2 blah" yourself is quite different. The
reason it works when blah is not executable is that you're actually
running /lib/ld-linux.so.2. The name blah never gets passed to the
kernel for exec'ing; ld-linux just loads it into memory and dynamic
links it (similar to if the kernel had utilized ld-linux.so for this)
and then transfers control to its entry point.

Rich