linux-kernel - Re: [AppArmor 00/41] AppArmor security module overview

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070416074612.GB2146@elf.ucw.cz>
Date:	Mon, 16 Apr 2007 09:46:12 +0200
From:	Pavel Machek <pavel@....cz>
To:	David Wagner <daw-usenet@...erner.cs.berkeley.edu>
Cc:	linux-kernel@...r.kernel.org
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/