lkml.org 
[lkml]   [1999]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] i386 ptrace patch needed for user-mode port
> Has anybody looked closely at possible security implications? I.e., switch
> system call numbers so "read" becomes "write" (or "exec") and run a
> program...

The security implications are well-understood. If I have ptrace access
to a program then I can scribble all over its memory, stuff new values in
its registers, and force it to do system calls (int 0x80) with the values
of my choice.

Therefore the security perimeter is around granting ptrace access,
not around what a ptrace owner can do to its slave.

As far as I can tell, the original prohibition on writing ORIG_EAX comes
about because the system call entry code could get derailed if it changed.
This is just an implementation issue and it went away a long time ago
when the "being traced" code moved out of the fast path.

I booted up Jeff Dike's patch back against 2.2.4 and it worked for then.
I haven't tried it since then. Also I haven't stared it for an hour
thinking if there's a way to mess up the kernel by providing illegal
values (it's designed so there isn't but that would be a real brown
paper bag bug).

I need a way to annul system calls so that I can play _Truman Show_
mind games on the target process. Right now I play with the arguments
but that doesn't work with argument-less calls such as fork().

That makes three people who want the same functionality (changing
system call number) for three unrelated reasons:

- user mode kernel
- trace-and-replay debugger
- strace vfork->fork

Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.030 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site