Hello all,

I'm investigating installing BOINC on potentially hundreds of servers (Linux) at an organization, but am looking for as much detail as possible regarding the security model and sandboxing (both account-based and vm-based) in order to convince admins that it would be safe. I found the following pages, but the second (more detail) says it describes the Macintosh sandboxing design and I'm specifically interested in Linux.

http://boinc.berkeley.edu/trac/wiki/SandboxUser
http://boinc.berkeley.edu/sandbox.php

Additionally, I'd like to know the following information if anyone can help here:

1) How are binaries linked (statically, dynamically)?
2) Does BOINC run the project programs inside a chroot jail?
3) Does BOINC employ any additional security measures, for instance ulimit for resource consumption limits, or SELinux for very granular access control?

Also, if you have any general suggestions for making BOINC installations secure beyond what's written in the link below, I'd appreciate it.

http://boinc.berkeley.edu/wiki/BOINC_Security

Many thanks in advance for any assistance. I don't have a great deal of time to allocate to this project, and I'd like to avoid reading through the BOINC code if possible.

Cheers,
Raku

Sorry for that troll that's posting in your thread. He'll just have to learn that when his account is banished, that he's not allowed back with a new one, until after his original account's been freed. Which will now be never.

---

I'll repost what the troll wants you to know so urgently:

Hello all,

I'm investigating installing BOINC on potentially hundreds of servers (Linux) at an organization, but am looking for as much detail as possible regarding the security model and sandboxing (both account-based and vm-based) in order to convince admins that it would be safe. I found the following pages, but the second (more detail) says it describes the Macintosh sandboxing design and I'm specifically interested in Linux.

First you should understand that there are 3 different ways to install BOINC on Linux. This page from the official BOINC wiki gives details but the 3 methods are: from package (repository), the Berkeley installer and "get the source and compile it yourself". Therefore the answer to many of your questions depends on which method you use to install BOINC and how it was compiled by the people who provide the installer.

The Berkeley installer simply puts the binaries in a subdirectory of your home directory and then you run the binaries on your own account. This is the least secure model. Of course the binaries don't have root access so there is always that basic protection but you would probably want more in your situation.

The BOINC package installers available from various most distros all do things slightly different but the one thing they all have in common is the fact that they create an unprivileged user named boinc and install BOINC client as a daemon service that runs on the boinc user account. The boinc user doesn't have a home dir, or password and has severely restricted access. boinc cannot access much of the video susbsystem or even mouse and keyboard, for example, and there are probably more restrictions I am unaware of. This model is far more secure than the Berkeley installer model.

The daemon then autostarts at boot time and there are various ways you can prevent other users from controlling the client. There are 3 binaries: boinc, boincmgr and boinccmd. Boinc (BOINC client) does all the real work, boincmgr (BOINC manager) is a GUI that controls the client with RPC over TCP on port 31416. boinccmd uses the same RPC but it's CLI rather than GUI. boincmgr and boinccmd both need a password to connect to the client so you only need to hide that password from other users to prevent them from controlling the client. Admins can SSH into the host and control the client via boinccmd or via BOINC manager running on a remote host, if they know the password.

On Linux daemons are created and launched via an init script which is just a bash (or whatever) script that init runs when it does the boot sequence. The process follows the traditional Sys V protocol. The installer places the init script in /etc/init.d and prefixes it with a number that determines the order that it runs in. Scripts with higher numbers runnear the end of the boot sequence, scripts with lower numbers run earlier. You can edit the init script to customize the way boinc (the client binary) runs and modify security related stuff there.

The daemon model is perfect for what you want. By controlling which system resources the user named boinc has access to you define the sandbox it is restricted to. The only way to achieve a tighter sandbox is to run it in a VM which I have done many times, it works very well.

1) How are binaries linked (statically, dynamically)?

Some are static, some dynamic. boincmgr has many dynamic linked libs whereas boinc has only 3, IIRC, and I believe you could easily compile it yourself and make those static if you wanted.

2) Does BOINC run the project programs inside a chroot jail?

The Berkeley installer does not do that. Various package installers available from distros might do that. I don't think the Ubuntu package does but I believe the Debian package does, maybe, don't quote me on it.

3) Does BOINC employ any additional security measures, for instance ulimit for resource consumption limits, or SELinux for very granular access control?

For the Berkeley installer the answer is no. For packages from distros... I don't think so but I might be wrong, I haven't tried them all.

Also, if you have any general suggestions for making BOINC installations secure beyond what's written in the link below, I'd appreciate it.

http://boinc.berkeley.edu/wiki/BOINC_Security

I haven't read that link yet and may not have time.

---

Thank you for your quick response (and apologies for my equally slow one).
The information you provided is very helpful.

Just a side note, but where did the info you quoted in your previous post come from? I missed all the emails from the troll thanks to your mediation, so no idea about that.

Emails about events like thread subscriptions and getting PMs works on my account, so I would assume they do on yours. But only when you have actually subscribed to your thread --it's a separate action, you have to do it, you're not automatically subscribed to threads you make yourself-- and you have set to be emailed about it in your forum preferences (top option).

I have PMed you about your other question.

---