linux-kernel - Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole

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: <20090510053629.GB1363@ucw.cz>
Date:	Sun, 10 May 2009 07:36:29 +0200
From:	Pavel Machek <pavel@....cz>
To:	David Wagner <daw-news@...berkeley.edu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole

Hi!

> >> Ptrace has performance and/or reliability problems when used to
> >> sandbox threaded applications due to potential race conditions when
> >> inspecting system call arguments. We hope that we can avoid this
> >> problem with seccomp.
> >
> >ptrace certainly has performance issues.  I take it the only "reliability
> >problems" you are talking about are MT races with modifications to user
> >memory that is relevant to a system call.  (Is there something else?)
> 
> As of 1999, I believe there were some other issues for using ptrace
> securely:
> 
> 1. I do not know of a good way to reliably ensure that all children of
> a traced program will be traced as well.  If you wait for the fork()
> call to return, check the pid, and start tracing the child process,
> you are subject to race conditions.  (strace's solution is to modify
> the code of the traced program to put a trapping instruction immediately
> after the call site to fork().  This is a grody hack and I had a hard
> time convincing myself that this will be secure in all cases.)
> 
> 2. ptrace disrupts the process hierarchy and Unix signals.  Because of
> the way ptrace overloads signals to deliver tracing events, tracing is
> not transparent.  For instance, if the parent and child are both traced,
> and the parent waits for a signal from the child, things may no longer
> work the same way while being traced.  Working around this requires
> non-trivial code.  Complexity is the enemy of security and makes it hard
> to gain confidence this doesn't introduce subtle issues.
> 
> 3. If the tracing application should happen to die unexpectedly
> (OOM, anyone?), I believe the traced application continues running,
> now without any security checks.
> 
> 4. I seem to recall that when I looked at this in 1999, if the traced
> app makes a syscall that should not be allowed, I couldn't find a good
> way to prevent that syscall from executing.  I don't know if current
> ptrace has solved this problem.
> 
> Disclaimer: I haven't checked whether these all still apply today.

subterfugue.net has ptrace-based monitor that is secure AFAICT. We
improved ptrace for it a bit...
								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/