Securely renting out your CPU with Linux [LWN.net]

One might think that hacking kernels for SuSE would be enough to keep a person busy, but Andrea Arcangeli has more energy than that. So, on the side, he is working on a project called cpushare. Essentially, it is a form of Linux-based worldwide grid network which would enable people to sell their idle CPU cycles to others who are in need of serious crunching power. Most systems sit idle most of the time; they might as well be working for a living instead.

Before Linux users will accept outside code on their systems, they will need to be pretty well convinced that said code can be kept under control. Without some pretty fierce security, a grid network could quickly be turned into a serious zombie network, and that would be embarrassing for everybody involved. The long-term plan is to take advantage of "trusted computing" hardware to sandbox the guest code; that hardware will also be able to help prevent the owner of the system from interfering with (or even observing) the buyer's computations and data. For now, however, some other method of ensuring the security of the host systems will have to be devised.

Andrea's answer is the seccomp patch. It is, in fact, an exceedingly simple solution to the problem. With this patch in place, the kernel allows a process to make a one-way transition into a "secure computing" mode. A hook is placed in the system call gate which checks for this mode; when secure computing is turned on, an attempt to execute almost any system call will result in the immediate termination of the process. The only exceptions are read(), write(), exit(), and the two forms of sigreturn(). So the cpushare client would execute outside work by setting up some sockets to communicate with the master system, turning on the secure mode, and executing the client code. If all goes well, that code will be able to do nothing beyond pure CPU use and communicating through the sockets given to it. And exiting, of course.

The objection that was raised is that this sort of sandboxing can be done from user space with ptrace(). At least, it can if one little patch is applied to ensure that the sandboxed process cannot continue if, somehow, the monitoring process dies first. Andrea acknowledges that the ptrace() solution is workable, but he still prefers the secure computing mode. The reason is simplicity: the seccomp patch is quite small, and it is relatively easy to verify that it does what is needed. The ptrace() code is rather more complex and harder to verify, even before considering the interactions with the user-space monitor.

The public discussion was inconclusive, so it is hard to predict whether this patch will eventually be accepted or not.

(Log in to post comments)

Consider plug-ins

Posted Jan 27, 2005 7:57 UTC (Thu) by eru (subscriber, #2753) [Link]

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).

Useful sandboxing for privilege separation

Posted Jan 27, 2005 11:13 UTC (Thu) by hmh (subscriber, #3838) [Link]

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.

Useful sandboxing for privilege separation

Posted Jan 27, 2005 16:01 UTC (Thu) by MathFox (guest, #6104) [Link]

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

Posted Jan 27, 2005 13:10 UTC (Thu) by davecb (subscriber, #1574) [Link]

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

Making it more useful.

Posted Jan 27, 2005 15:19 UTC (Thu) by brugolsky (subscriber, #28) [Link]

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

Posted Jan 28, 2005 23:23 UTC (Fri) by mongre26 (guest, #4224) [Link]

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.

`Securely' for who?

Posted Feb 25, 2005 15:10 UTC (Fri) by shane (subscriber, #3335) [Link]

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. :)