From: Andrea Arcangeli <andrea@cpushare.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@osdl.org>, Adrian Bunk <bunk@stusta.de>,
linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: Re: [-mm patch] seccomp: don't say it was more or less mandatory
Date: Tue, 15 Mar 2005 17:44:20 +0100 [thread overview]
Message-ID: <20050315164420.GT7699@opteron.random> (raw)
In-Reply-To: <20050315150526.GA14744@elte.hu>
Oe Tue, Mar 15, 2005 at 04:05:26PM +0100, Ingo Molnar wrote:
> ugh? Where do i claim any such thing?
You never said such a thing, but you said you believe it's not provable
that sys_read/write and hardware irq processing is secure in linux, so
I wanted to get some statistical significance about your claim from you
just in case I was missing something. I obviously can't have in memory
every single bug since 2.4.0.
> while we are at it, please mention a single ptrace bug in the same
> timeframe that could allow a bytecode 'client' to escape a ptrace
> TRACE_SYSCALL jail at will.
There was this bug around 2.4.10, IIRC a SIGCONT could let the ptraced
task to continue executing. I don't want to depend on other applications
not to send a signal by mistake to the ptraced task.
http://www.ussg.iu.edu/hypermail/linux/kernel/0109.0/1049.html
An oom killer triggering by mistake on a strace -p would have been
enough too. You said if the ptracer is the group leader then the ptraced
task will be killed at the same time, but I doubt many apps depends on
this to be safe, that code is complex and it may break over time during
development if signal handling changes or if the exit code changes.
The interesting point is that no app out there (except uml) becomes
exploitable if you find some hole in TRACE_SYSCALL (at worse strace will
screwup a bit). I don't think an huge amount of research has been done
in those code paths (unlike it happened in mremap and many other kernel
APIs). So even if there are bugs in ptrace they might not being
considered security related. And UML has no other way than to use ptrace
since it needs much more of what I need and UML cannot be arch
indipendent.
While any seccomp security bug is guaranteed to be a major security
linux bug too, so I'm more confortable that more research has been done
in those core code paths than in TRACE_SYSCALL behaviour.
This below is all the code I had to write to secure the remote bytecode
with seccomp, and it's fully arch indipendent (licence is LGPL). Ok,
the seccomp kernel patch is 500 lines, so we should add 500 lines plus
the below ~50 total ~550 lines, but the end result is much nicer and
more secure IMHO. Plus this is simple enough that perhaps Cpushare won't
be the only project using it.
class seccomp_protocol_class(protocol.ProcessProtocol):
def __init__(self, seccomp, d_start, d_end):
self.seccomp = seccomp
self.d_start, self.d_end = d_start, d_end
self.outReceived = self.enable_seccomp_mode
def connectionMade(self):
self.seccomp.cpushare_protocol.seccomp_protocols.append(self)
self.seccomp.cpushare_protocol.transport.registerProducer(self, 1)
self.transport.closeChildFD(2) # close stderr right away
self.transport.writeToChild(0, self.seccomp.header + self.seccomp.text_data)
def enable_seccomp_mode(self, data):
assert data == MAGIC_ASK_SECCOMP, "didn't ask seccomp"
seccomp_file = '/proc/' + str(self.transport.pid) + '/seccomp'
if file(seccomp_file, 'r').read(1) != '0':
raise 'seccomp already enabled?'
file(seccomp_file, 'w').write('1')
if file(seccomp_file, 'r').read(1) != '1':
assert self.transport.pid is not None
print 'Killing the seccomp-loader before it starts the untrusted bytecode'
self.sigkill()
raise 'seccomp enable failure'
self.outReceived = self.send_to_server
self.transport.writeToChild(0, MAGIC_GOT_SECCOMP)
self.d_start.callback(None) # now the buyer is connected
def send_to_server(self, data):
self.seccomp.cpushare_protocol.sendString(PROTO_SECCOMP_FORWARD + data)
def recv_from_server(self, data):
self.transport.writeToChild(0, data)
def errReceived(self, data):
raise "shouldn't happen"
def processEnded(self, status):
self.seccomp.cpushare_protocol.seccomp_protocols.remove(self)
self.seccomp.cpushare_protocol.transport.unregisterProducer()
if status.value.exitCode or status.value.signal:
if status.value.exitCode == 4:
print 'Failure in setting the stack size to %d bytes.' % self.seccomp.stack
if status.value.signal == signal.SIGKILL:
print 'Seccomp task gracefully killed by seccomp.'
elif status.value.signal == signal.SIGSEGV:
print 'Seccomp task gracefully killed by sigsegv.'
elif status.value.signal == signal.SIGQUIT:
print 'Seccomp task killed by sigquit - should never happen.'
self.d_end.errback(status)
else:
print 'Seccomp task completed successfully.'
self.d_end.callback(None)
def sigquit(self):
if self.transport.pid is not None:
os.kill(self.transport.pid, signal.SIGQUIT)
def sigkill(self):
if self.transport.pid is not None:
os.kill(self.transport.pid, signal.SIGKILL)
next prev parent reply other threads:[~2005-03-15 16:45 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-23 9:42 2.6.11-rc4-mm1 Andrew Morton
2005-02-23 11:03 ` 2.6.11-rc4-mm1 Mathieu Segaud
2005-02-23 16:32 ` 2.6.11-rc4-mm1 Robert Love
2005-02-23 13:06 ` 2.6.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ? Helge Hafting
2005-02-23 20:12 ` Andrew Morton
2005-02-23 22:36 ` Laurent Riffard
2005-02-23 23:11 ` Matt Mackall
2005-02-23 23:20 ` Andrew Morton
2005-02-24 17:02 ` Laurent Riffard
2005-02-23 23:47 ` Greg KH
2005-02-24 17:06 ` Laurent Riffard
2005-02-24 17:18 ` Greg KH
2005-02-24 20:42 ` Laurent Riffard
2005-02-24 23:17 ` Greg KH
2005-02-23 23:32 ` Mathieu Segaud
2005-02-24 0:17 ` Matt Mackall
2005-02-23 16:37 ` 2.6.11-rc4-mm1 (VFS: Cannot open root device "301") Steven Cole
2005-02-23 20:17 ` Andrew Morton
2005-02-23 22:10 ` Steven Cole
2005-02-23 22:54 ` Steven Cole
2005-02-24 0:16 ` Andrew Morton
2005-02-24 0:25 ` Andrew Morton
2005-02-24 13:19 ` Bartlomiej Zolnierkiewicz
2005-02-25 0:20 ` Felipe Alfaro Solana
2005-02-24 0:41 ` Matt Mackall
2005-02-24 2:03 ` Benoit Boissinot
2005-02-24 2:08 ` Matt Mackall
2005-02-23 23:03 ` Andrew Morton
2005-02-23 23:03 ` Matt Mackall
2005-02-24 0:44 ` Matt Mackall
2005-02-24 15:59 ` Steven Cole
2005-02-24 16:18 ` Steven Cole
2005-02-23 22:45 ` Matt Mackall
2005-02-23 17:07 ` 2.6.11-rc4-mm1 Vincent Vanackere
2005-02-23 18:20 ` 2.6.11-rc4-mm1 Brice Goglin
2005-02-23 21:24 ` 2.6.11-rc4-mm1 Dominik Brodowski
2005-02-23 22:00 ` 2.6.11-rc4-mm1 Brice Goglin
2005-02-23 23:56 ` 2.6.11-rc4-mm1 Brice Goglin
2005-02-23 21:05 ` 2.6.11-rc4-mm1 Benoit Boissinot
2005-02-23 21:42 ` [PATCH] process-wide itimer typo fixes Roland McGrath
2005-02-23 21:30 ` 2.6.11-rc4-mm1 Adrian Bunk
2005-02-23 21:49 ` 2.6.11-rc4-mm1 (compile stats) John Cherry
2005-02-23 22:22 ` 2.6.11-rc4-mm1 Francois Romieu
2005-02-23 22:38 ` 2.6.11-rc4-mm1 J.A. Magallon
2005-02-23 23:12 ` 2.6.11-rc4-mm1 Ed Tomlinson
2005-02-23 23:40 ` 2.6.11-rc4-mm1 Dmitry Torokhov
2005-02-24 0:20 ` 2.6.11-rc4-mm1 Ed Tomlinson
2005-02-24 0:26 ` 2.6.11-rc4-mm1 Fabian Fenaut
2005-02-25 0:06 ` 2.6.11-rc4-mm1 J.A. Magallon
2005-02-25 3:18 ` 2.6.11-rc4-mm1 Dmitry Torokhov
2005-02-23 23:07 ` 2.6.11-rc4-mm1 Ed Tomlinson
2005-02-23 23:25 ` 2.6.11-rc4-mm1 Andrew Morton
2005-02-24 11:11 ` 2.6.11-rc4-mm1: infiniband/core/user_mad.c warning Adrian Bunk
2005-02-24 11:11 ` [-mm patch] drivers/md/dm-hw-handler.c: fix compile warnings Adrian Bunk
2005-02-24 21:51 ` [-mm patch] seccomp: don't say it was more or less mandatory Adrian Bunk
2005-02-24 22:41 ` Andrea Arcangeli
2005-02-25 21:14 ` Adrian Bunk
2005-02-26 1:31 ` Andrea Arcangeli
2005-03-01 0:32 ` Adrian Bunk
2005-03-01 0:44 ` Andrea Arcangeli
2005-03-03 14:51 ` Adrian Bunk
2005-03-03 16:24 ` Andrea Arcangeli
2005-03-03 21:55 ` Andrew Morton
2005-03-15 10:09 ` Ingo Molnar
2005-03-15 10:15 ` Ingo Molnar
2005-03-15 11:27 ` Ingo Molnar
2005-03-15 13:00 ` Andrea Arcangeli
2005-03-15 14:44 ` Ingo Molnar
2005-03-15 14:59 ` Andrea Arcangeli
2005-03-15 15:00 ` Ingo Molnar
2005-03-15 15:05 ` Ingo Molnar
2005-03-15 16:44 ` Andrea Arcangeli [this message]
2005-03-16 8:28 ` Ingo Molnar
2005-03-16 10:46 ` Andrea Arcangeli
2005-03-16 13:41 ` Ingo Molnar
2005-03-16 17:28 ` Andrea Arcangeli
2005-03-17 10:27 ` Ingo Molnar
2005-03-17 10:49 ` Andrea Arcangeli
2005-02-26 11:31 ` [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Adrian Bunk
2005-03-02 6:43 ` Jeff Garzik
2005-03-02 14:08 ` Adrian Bunk
2005-03-02 19:12 ` Jeff Garzik
2005-03-02 20:38 ` Andrew Morton
2005-03-02 21:07 ` Jeff Garzik
2005-03-02 21:18 ` Andrew Morton
2005-03-02 21:56 ` Adrian Bunk
2005-03-02 22:14 ` Andrew Morton
2005-03-02 22:41 ` Jeff Garzik
2005-03-02 22:45 ` Adrian Bunk
2005-03-02 22:49 ` Jeff Garzik
2005-03-03 15:07 ` How to handle the multiple aes variants on i386? Adrian Bunk
2005-03-02 21:59 ` [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Adrian Bunk
2005-02-27 15:48 ` [2.6.11-rc4-mm1 patch] drivers/scsi/arcmsr/arcmsr.c cleanups Adrian Bunk
2005-02-27 22:23 ` Christoph Hellwig
2005-02-28 18:07 ` [-mm patch] drivers/scsi/ch.c: make a struct static Adrian Bunk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050315164420.GT7699@opteron.random \
--to=andrea@cpushare.com \
--cc=akpm@osdl.org \
--cc=bunk@stusta.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox