Messages in this thread | | | Date | Mon, 16 Apr 2007 09:46:12 +0200 | From | Pavel Machek <> | Subject | Re: [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/
| |