lkml.org 
[lkml]   [2007]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [AppArmor 00/41] AppArmor security module overview
Hi!

> >You can do the same with ptrace. If that's not fast enough... improve
> >ptrace?
>
> I did my Master's thesis on a system called Janus that tried using ptrace
> for this goal. The bottom line is that ptrace sucks for this purpose.
> It is a kludge. It is not the right approach. I do not know of any
> satisfactory way to improve ptrace for this purpose; you have to throw
> away ptrace and start over.
>
> At the time I did the work, ptrace has all sorts of serious problems.
> Here are some of them. There was no way to follow fork securely.

Actually there is now. I did something similar called subterfugue and
we solved this one.

> There was no way to deny a single system call without killing the process
> entirely. Performance was poor, because ptrace context-switches on
> every
> read() and write().

You can't deny a system call, but you can turn it into getpid(), then
fake the return value. You probably could invent ptrace extensions,
like solaris did, to avoid context switches.

> Handling of signals is a mess: ptrace overloads the
> signal mechanism to deliver its events, which in retrospect was a lousy
> design decision it makes the tracer complex and error-prone and makes
> it hard to maintain the transparency of tracing. ptrace breaks wait(),
> and consequently handling wait() and other signal-related system calls
> transparently and securely is ugly at best

We got this solved in linux, I believe.

> . Handling signals is probably
> feasible but a total mess, and that's the last thing you want in the
> security-critical part of your system. In addition, ptrace operates
> at the wrong level of abstraction and forces the user-level tracer to
> maintain a lot of shadow state that must be kept in sync with state held
> by the kernel. That's an opportunity for security holes. Also, ptrace
> has no way to force the tracee to die if the tracer unexpectedly dies,
> which is risky when using ptrace for security confinement.

I think we actually have a flag for "kill this if tracer dies"... or
we could add it.

> I haven't
> checked whether these problems are still present in the current
> implementation of ptrace, but I'd guess that many probably still are,
> because many are fundamental consequences of how ptrace works.
>
> Before advocating ptrace for this purpose, I encourage you to study some
> of the relevant literature. Start with Chapter 4 of my Master's
> thesis.

I'm not advocating it. I've done this before, see subterfugue.org. It
was a ugly hack, mostly because it was filename based. Unfortunately
AA is also filename-based.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-04-16 09:49    [W:0.221 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site