LWN: Comments on "Securely renting out your CPU with Linux"

`Securely' for who?

shane — Fri, 25 Feb 2005 15:10:01 +0000

Interesting question. It depends on the nature of the computation that you are doing, I suppose. There are lots of computations that are easier to check than to do. Division is a good example.

A related, and more tricky question, is whether or not you could ever do computation on someone's computer without them being able to know what you are doing.

You can do certain operations on remote computers with a degree of safety. For instance, you can store data on a distributed file system, if you encrypt it.

For more traditional computation it is difficult to know what it is possible to hide or not. If you wanted someone to do work for you, but not know what they were doing, you can take steps. Getting back to division, you could multiply both the numerator and denominator by the same amount, and know that the results of the division would be the same. The person doing the work for you would have no way to know which two numbers you are dividing, and still be able to give you a result you can use. Plus you can check it when you get the result back.

Of course, the person doing this work will still know that division is being done, so the operation isn't completely transparent.

It gets trickier still when you are executing a series of operations. For instance, if you have a function that consists of a division followed by an addition, then you cannot simply scale the numbers as before.

I'm not sure what is possible and what isn't, only that *something* is possible. I've actually considered proposing this as a PhD topic and going back to school. :)

`Securely' for who?

raboofje — Sat, 05 Feb 2005 11:03:59 +0000

I can see how this could be `secure' for those supplying the CPU power.

But how can you ever trust the results of the calculations?

Securely renting out your CPU with Linux

mongre26 — Fri, 28 Jan 2005 23:23:46 +0000

I can definitely see this being useful for grid computing and I could see myself deploying this in my environment.

Sure you could probably use some SELinux arrangement, but this is vastly simpler. It remindes me of systrace but assumes even less as far as profiling the app in question. Right up front it defines the limitations. Work within it, or leave.

As grid computing spreads and more projects take advantage of the significant amount of computing out there for inter project work this could be very useful to provide a simple yet effective way to sandbox grid processes.

When I say computing, I do not mean peoples desktops. Sure they can be used for some projects, but combine multi-gigabit networking with hundreds of nodes in a cluster with terabytes of storage and the domain of problems you can tackle grows fast. There are hundreds of small 100-500 Teraflop scale clusters out there that can be connected to maximize their utilization and techniques like this are just what is required to increase they security.

interesting synergy

dlang — Fri, 28 Jan 2005 04:55:31 +0000

Linux comes up with his idea to drasticly speed up pipes (along with the splice and tee capabilities) and Andrea comes up with his idea to lock down processes to only be able to access open fd's (like pipes)

I see some very interesting combinations of these two showing up in a little bit

Securely renting out your CPU with Linux

giraffedata — Thu, 27 Jan 2005 23:20:49 +0000

I would hate to see this be a special purpose thing, when the existing Linux capability concept fits it so well. Require certain capabilities to do all those forbidden system calls, and then exec the tenant program without those capabilities.

Securely renting out your CPU with Linux

popinet — Thu, 27 Jan 2005 21:13:19 +0000

It already exists: it's called openmosix.

And it works too...

cheers

Stephane

Useful sandboxing for privilege separation

MathFox — Thu, 27 Jan 2005 16:01:07 +0000

What you are talking about are actually "Process based access controls" that implement a security policy on a per-process basis.
I do think that it is great to have something like that in the kernel, but the present patch is a bit crude. (Can it run an embedded Acrobat Reader in a browser-controlled sandbox?) We'll need some discussion about the design and desired functionality.

Securely renting out your CPU with Linux

smoogen — Thu, 27 Jan 2005 15:19:57 +0000

This is also one of the features that OpenSolaris 10 is supposed to be spearheading.. a secure way of doing grid computing. It is probably patented 10 ways from Sunday for such a simple thing.

Making it more useful.

brugolsky — Thu, 27 Jan 2005 15:19:51 +0000

To be more generally useful, the process probably wants access to other system calls that simply access file descriptors, e.g. poll(). Passing file descriptors might also be desirable. Architectures with vsyscalls can do gettimeofday() from user space, but not every architecture implements it.

The great virtue of Andrea's mechanism is that it is rather difficult to get read()/write() wrong -- there's little in the way of syscall argument processing, with potential fence-post errors, etc.

But to provide additional functionality, one needs to implement an RPC mechanism to a managing process (talking over some file descriptor passed to the secured process) anyway, in which case one has to ask, which is more secure? As soon as the number of "RPC-like" services provided by the manager process multiplies, one has to worry about security in the manager process.

Securely renting out your CPU with Linux

davecb — Thu, 27 Jan 2005 13:10:08 +0000

An excellent idea for a department full of fat clients:
instead of letting them sit idle when there is work to
be done, let them contribute to it.

Natural extensions to this might include
- find-grained capabilities, and a command to
set a selected subset of them
- a fair-share scheduler, or at least one with
a "use CPU only when no other process wants
it" scheduling class.

--dave

Useful sandboxing for privilege separation

hmh — Thu, 27 Jan 2005 11:13:16 +0000

Exactly. Add some read/write-related syscals (epool, select, pool, shutdown, fseek and friends, ioctl, mmap of already open FDs...), plus signal handling, and this code would really be useful to create worker children that simply cannot step outside of their very strict bounds.

Give it two security levels (the first one does not give access to seek, ioctl or mmap, or any other non-socket operations), and it would still be useful for grid computing.

It is a pretty exiting idea, overall. AND it is something we can use everywhere when available easily, unlike SELinux.

Securely renting out your CPU with Linux

ttonino — Thu, 27 Jan 2005 08:31:18 +0000

I see multiple uses: it could be an effective sandbox mechanism for things that have can work over a pipe. Could be as complex as a PDF or PostScript renderer even.

Consider plug-ins

eru — Thu, 27 Jan 2005 07:57:45 +0000

To me the patch sounds like something that could have lots of other uses besides renting CPU:s. For example, it might enable a secure "ActiveX-like" native code plug-in system for browsers (or other extendable apps). The plug-in would communicate only through file descriptors open at the time it is called, and would be completely unable to mess with anything else (unlike a Windows ActiveX control).

Securely renting out your CPU with Linux

xorbe — Thu, 27 Jan 2005 07:03:34 +0000

Why is this being shoe-horned in? Are people asking for this junk?