Valery Reznic wrote:
Actually, I can think of four or five reasons why it may
fail, but I'll
cross those bridges when I get to them.
Could you list them ?
Let's see. Off the top of my head, these are not necessarily "won't
work" problems, but obstacles to overcome:
- I need to execute several syscalls in the process context. Usually
that is a solved problem, as I turn the syscall it was doing anyways
into a mmap, put the command for syscall in the memory I allocate, and
then set the program counter there for any additional syscall I need.
This won't work here because the process is not entering a syscall.
- So we need to initiate a syscall. If the stack is executable, we can
write a "syscall" command there. If not, we need to look for one inside
the code. Long and slow process.
- When the kernel loads the interpreter, it uses a different load
address than when it loads it as an executable. This may cause problems
for us.
- The memory WE allocate is allocated earlier than we would before. It
may interfere with other things.
It will allow me to control both which executable is loaded
AND which
interpreter, thus allowing me to emulate the chroot
syscall, adding
I don't think so. You intercept execve syscall, and instead of
<program> <args>
you give it
<interpreter> <program> <args>
There are three parameters that we need to control, and only two that
are passed to execve. The three are "which executable to use", "which
interpreter to load it with" and "what to call argv[0]". My way allows
controlling all three, your way allows no control over how argv[0] is
called. I thought of it, and decided it's enough of a problem to justify
the horrendous thing I'm suggesting here.
I don't remember all of the reasons why I abandoned this route (one of
them is what appears on "ps", btw), so I don't remember the details, but
I believe you may also have problems if you try to run a shell script
that runs a binary that needs an interpreter (i.e. - any shell script).
I.e you already have full control of both program and interpreter that are
going to be loaded.
But after you execve as
ld-linux program args
tricking interpreter to think that it was loaded directly should be a problem.
Which is why I touch execve's first argument (the command to run), but
not the second (the command line to pass it). I am running ld-linux with
a command line that is nonsense to it, but then patch the runtime
environment so that the command line retroactively makes sense again.
This way, ps still displays the right thing.
Unless you are going to change argc/argv before interpreter get control.
But why bother ?
execve interpreter looks like good solution.
Maybe if the above problems prove too much. I don't want to lose argv[0]
control just yet.
Valery.
Shachar
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
