Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261520AbVAXPKZ (ORCPT ); Mon, 24 Jan 2005 10:10:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261521AbVAXPKZ (ORCPT ); Mon, 24 Jan 2005 10:10:25 -0500 Received: from nevyn.them.org ([66.93.172.17]:63620 "EHLO nevyn.them.org") by vger.kernel.org with ESMTP id S261520AbVAXPKD (ORCPT ); Mon, 24 Jan 2005 10:10:03 -0500 Date: Mon, 24 Jan 2005 10:10:00 -0500 From: Daniel Jacobowitz To: David Wagner Cc: linux-kernel@vger.kernel.org Subject: Re: seccomp for 2.6.11-rc1-bk8 Message-ID: <20050124150959.GA21573@nevyn.them.org> Mail-Followup-To: David Wagner , linux-kernel@vger.kernel.org References: <20050121100606.GB8042@dualathlon.random> <20050121093902.O469@build.pdx.osdl.net> <20050121111700.Q469@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2394 Lines: 44 On Sun, Jan 23, 2005 at 07:34:24AM +0000, David Wagner wrote: > Chris Wright wrote: > >* David Wagner (daw@taverner.cs.berkeley.edu) wrote: > >> There is a simple tweak to ptrace which fixes that: one could add an > >> API to specify a set of syscalls that ptrace should not trap on. To get > >> seccomp-like semantics, the user program could specify {read,write}, but > >> if the user program ever wants to change its policy, it could change that > >> set. Solaris /proc (which is what is used for tracing) has this feature. > >> I coded up such an extension to ptrace semantics a long time ago, and > >> it seemed to work fine for me, though of course I am not a ptrace expert. > > > >Hmm, yeah, that'd be nice. That only leaves the issue of tracer dying > >(say from that crazy oom killer ;-). > > Yes, I also implemented was a ptrace option which causes the child to be > slaughtered if the parent dies for any reason. I could dig up the code, > but I don't recall it being very hard. This was ages ago (a 2.0.x kernel) > and I have no idea what might have changed. Also, am definitely not a > guru on kernel internals, so it is always possible I missed something. > But, at least on the surface this doesn't seem hard to implement. Maybe it's time to resubmit both of these. OTOH, maybe it's time to do something more drastic to ptrace to untangle it from signals... > A third thing I implemented was a option which would cause ptrace() to be > inherited across forks. The way that strace does this (last I looked) > is an unreliable abomination: when it sees a request to call fork(), it > sets a breakpoint at the next instruction after the fork() by re-writing > the code of the parent, then when that breakpoint triggers it attaches to > the child, restores the parent's code, and lets them continue executing. > This is icky, and I have little confidence in its security to prevent > children from escaping a ptrace() jail, so I added a feature to ptrace() > that remedies the situation. This has since been done in 2.5.x; see PTRACE_EVENT_FORK. GDB even uses it nowadays. I'm not sure if strace does. -- Daniel Jacobowitz - 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/