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: <f00f12$th4$1@taverner.cs.berkeley.edu>
Date:	Mon, 16 Apr 2007 18:24:34 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: [AppArmor 00/41] AppArmor security module overview

Pavel Machek  wrote:
> David Wagner wrote:
>> There was no way to follow fork securely.
>
>Actually there is now. I did something similar called subterfugue and
>we solved this one.

Yes, I saw that.  I thought subterfugue was neat.  The way that
subterfugue was a clever hack -- albeit too clever by half, in my opinion.
Dynamically re-writing the program on the fly to insert a trap after
the fork() call, right?  When the tracer has to do that kind of thing,
I find it hard to get confidence that it will be secure.  It seems
all too easy to imagine ways that the tracee might be able to escape
the tracing and break security.  There are all sorts of corner cases
to think about.  What if the program is executing from shared memory?
What if there are multiple threads running concurrently?  What if the
program is executing from a region of memory where a DMA is scheduled to
asynchronously write to?  Any of those cases could create a race condition
(TOCTTOU) where the trap after the fork() gets removed before the program
reaches that point of execution.

ptrace() seems like a fine answer for a debugger, but I think it's not
such a great answer for a security tool where you have to be dead-certain
there is no way to escape the sandbox.  When I'm relying upon something
for security, the last thing you want is to have to go through hairy
kludgy kludgy contortions to make up for flaws in the interface.
Complexity is the enemy of security.

I still think that ptrace() is not the best way to implement this kind
of security tool, and I think it's entirely understandable that they did
not use ptrace.  I do not think it is a fair criticism of AppArmor to say
"AppArmor should have used ptrace()".

>>  Handling of signals is a mess: ptrace overloads the
>> signal mechanism to deliver its events, [...]
>
>We got this solved in linux, I believe.

Out of curiousity, how was this solved?  It looked pretty fundamental
to me.

Thanks for your comments...
-
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/