Securely renting out your CPU with Linux
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.
| Index entries for this article | |
|---|---|
| Kernel | Security |
Posted Jan 27, 2005 7:03 UTC (Thu)
by xorbe (guest, #3165)
[Link] (1 responses)
Posted Jan 27, 2005 7:57 UTC (Thu)
by eru (subscriber, #2753)
[Link]
Posted Jan 27, 2005 8:31 UTC (Thu)
by ttonino (guest, #4073)
[Link] (2 responses)
Posted Jan 27, 2005 11:13 UTC (Thu)
by hmh (subscriber, #3838)
[Link] (1 responses)
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.
Posted Jan 27, 2005 16:01 UTC (Thu)
by MathFox (guest, #6104)
[Link]
Posted Jan 27, 2005 13:10 UTC (Thu)
by davecb (subscriber, #1574)
[Link] (1 responses)
Natural extensions to this might include
--dave
Posted Jan 27, 2005 21:13 UTC (Thu)
by popinet (guest, #5248)
[Link]
And it works too...
cheers
Stephane
Posted Jan 27, 2005 15:19 UTC (Thu)
by brugolsky (guest, #28)
[Link]
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.
Posted Jan 27, 2005 15:19 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
Posted Jan 27, 2005 23:20 UTC (Thu)
by giraffedata (guest, #1954)
[Link]
Posted Jan 28, 2005 4:55 UTC (Fri)
by dlang (guest, #313)
[Link]
I see some very interesting combinations of these two showing up in a little bit
Posted Jan 28, 2005 23:23 UTC (Fri)
by mongre26 (guest, #4224)
[Link]
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.
Posted Feb 5, 2005 11:03 UTC (Sat)
by raboofje (guest, #26972)
[Link] (1 responses)
But how can you ever trust the results of the calculations?
Posted Feb 25, 2005 15:10 UTC (Fri)
by shane (subscriber, #3335)
[Link]
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. :)
Why is this being shoe-horned in? Are people asking for this junk?Securely renting out your CPU with Linux
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).
Consider plug-ins
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.Securely renting out your CPU with Linux
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. Useful sandboxing for privilege separation
What you are talking about are actually "Process based access controls" that implement a security policy on a per-process basis.Useful sandboxing for privilege separation
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.
An excellent idea for a department full of fat clients:Securely renting out your CPU with Linux
instead of letting them sit idle when there is work to
be done, let them contribute to it.
- 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.
It already exists: it's called openmosix.Securely renting out your CPU with Linux
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.Making it more useful.
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.Securely renting out your CPU with Linux
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
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)interesting synergy
I can definitely see this being useful for grid computing and I could see myself deploying this in my environment. Securely renting out your CPU with Linux
I can see how this could be `secure' for those supplying the CPU power.`Securely' for who?
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.
`Securely' for who?