On Sun, Jul 04, 2004 at 02:35:26PM -0700, Andrew Morton wrote:
> Of course, yes, the patch is sufficiently safe and simple for it to be
> mergeable in 2.6, if this is the way we want to do secure computing. I'd
> wonder whether the API should be syscall-based rather than /proc-based, and
> whether there should be a config option for it.
here a new patch, possibly candidate for merging in 2.6.10pre?
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.9-rc4/seccomp
I added the config option, mostly to be sure archs will show the seccomp
file only if they really support the feature interally.
For my purpose seccomp is the most robust and secure API I could desire.
Adding genericity isn't the object, the object is to keep it simple and
obviously safe and as hard as possible to break. I plan to eventually
go a bit more complex (and in turn a bit less secure from the point of
view of the seller) with xen-like trusted computing later once there
will be enough hardware in the market to make it worthwhile. As for the
syscall vs /proc, it's not performance critical, and I find this more
usable (plus currently I'm firing it on with python and excuting a new
syscalls with python isn't as quick as a file('/proc/' + pid +
'/seccomp', 'w').write('1').
Also note, I don't mind if the seccomp file could be removed from /proc
eventually, as far as I have the guarantee that when it's in there it
implements the feature. Ideally the seccomp.c file should be pretty much
fixed in stone and not subject to any further kernel development.
To receive the data asynchronously SIGIO can be set by the
seccomp-loader, or it can simply retry some read syscall from the socket
once every couple of seconds if the buffer isn't already full (socket
can be set in nonblocking mode). That's all userspace stuff that
belongs to the seccomp loader. On the kernel side I will make it with
only read/write/exit/sigreturn. Even once trusted computing will be
enabled I will only allow those few operations to communicate with the
untrusted world. So the model is going to stay and this also means
ideally no bytecode would require modification to run in trusted
computing mode by just creating a proper trusted-seccomp-loader (we'll
see if this is really true, I think it's at least theoretically
feasible, but it's not a short term matter).
It's a pain to program inside the seccomp mode for the programmer, but
the power he/she will get if he does I believe could make it worthwhile
and the whole thing worth a quick try.
Another reason for merging this is that projects like BOINC should start
using seccomp too. They write in their webpage "Accidental abuse of
participant hosts by projects: BOINC does nothing to prevent this. The
chances of it happening can be minimized by pre-released application
testing. Projects should test their applications thoroughly on all
platforms and with all input data scenarios before promoting them to
production status.". seccomp will fix it completely, which means the
userbase could increase significantly too, beacuse the seller will not
have to trust the buyer not to have bugs.
Relaying on seccomp not to break (like I'm doing) is no different from
relaying on the netfilter code not to break and it's no different from
relaying on the openssh code not to break, and again no different from
relaying on the IPSEC code not to break. Except this is an order of
magnitude simpler to guarantee as obviously safe since much less kernel
code is involved in these secure paths. Plus this is a lot more secure
too since if something breaks I will force an upgrade immediatly on
every single client connected and I'll notify via email as well anybody
who could have been affeected, something not enforceable on firewall
kernel code for example on a random computer on the internet.
On Tue, 12 Oct 2004, Andrea Arcangeli wrote:
> here a new patch, possibly candidate for merging in 2.6.10pre?
>
> http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.9-rc4/seccomp
How do you start a seccomp process in a secure way ?
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
On Tue, Oct 12, 2004 at 11:32:57AM -0400, Rik van Riel wrote:
> On Tue, 12 Oct 2004, Andrea Arcangeli wrote:
>
> > here a new patch, possibly candidate for merging in 2.6.10pre?
> >
> > http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.9-rc4/seccomp
>
> How do you start a seccomp process in a secure way ?
there's an example here:
http://www.cpushare.com/download/cpushare-0.4.tar.bz2
check python seccomp_test.py and seccomp-loader.c.
On Tue, 12 Oct 2004, Andrea Arcangeli wrote:
> http://www.cpushare.com/download/cpushare-0.4.tar.bz2
>
> check python seccomp_test.py and seccomp-loader.c.
Looks like it should work, though really only for the
purposes of cpushare and nothing else.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
On Tue, Oct 12, 2004 at 12:28:48PM -0400, Rik van Riel wrote:
> Looks like it should work, though really only for the
> purposes of cpushare and nothing else.
in the short term I sure agree, and in my humble opinion this is true
for trusted computing too.
However as said boinc and seti would better start using it too.
And people could start using it for other things too every time they
deal with untrusted data or bytecode. The parsing untrusted data case is
especially easy since it won't even require the seccom-loader (since the
executable is trusted before it starts managing the untrusted data
coming from the network). For example you can parse the jpeg into a
seccomp mode task, that gets the jpeg in input of the pipe and it throws
the uncompressed bitmap in output ready to be written in the
framebuffer. Basically every decompression scheme can run in a task
running in seccomp mode and for most usages the only risk is to see or
listen to garbage, but no exploit once the raw data is pushed into the
hardware as "raw data".
On Tue, 12 Oct 2004, Andrea Arcangeli wrote:
> On Tue, Oct 12, 2004 at 12:28:48PM -0400, Rik van Riel wrote:
> > Looks like it should work, though really only for the
> > purposes of cpushare and nothing else.
> However as said boinc and seti would better start using it too.
Are they interested ?
> And people could start using it for other things too every time they
> deal with untrusted data or bytecode.
Would be interesting for eg. browser plugins, though I don't
know whether the current seccomp infrastructure is powerful
enough for that ...
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
On Tue, 12 Oct 2004, Andrea Arcangeli wrote:
> However as said boinc and seti would better start using it too.
Thinking about it some more, I'm not convinced they can.
After all, they need to get new data to perform calculations
on, and pass the results of previous calculations on to the
server.
In order to do that, the user needs to run code that's not
restricted by seccomp. Taking that into account, what's the
point ?
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
On Tue, Oct 12, 2004 at 02:10:52PM -0400, Rik van Riel wrote:
> On Tue, 12 Oct 2004, Andrea Arcangeli wrote:
>
> > However as said boinc and seti would better start using it too.
>
> Thinking about it some more, I'm not convinced they can.
>
> After all, they need to get new data to perform calculations
> on, and pass the results of previous calculations on to the
> server.
>
> In order to do that, the user needs to run code that's not
> restricted by seccomp. [..]
Getting new data to performance calculations and pass the results up to
the buyer is what I'm doing too and it's the ideal workload to use
with seccomp or trusted computing. But this is very offtopic discussion
for this list.
jpeg sure can be decompressed too.