It may be somewhere in the systemd implementation

Right while I was typing. :-)

the permissions I could read were 777

1777 for me, where the 1 didn't allow me to easily see if it was 1777 or 1776. The latter could have been the problem but 1777 it was.

But isn't BOINC supposed to be sandboxed under systemd. Could that block out the rest of the world?

If I'm right BOINC is blocked out from the rest of the world here.

If I'm right BOINC is blocked out from the rest of the world here.

The point is that BOINC is allowed to download and execute binaries from the projects. I don't think it's ever happened (yet!), but a project could be hacked or go rogue, and start distributing malware. That shouldn't be allowed to escape into the host operating environment.

BOINC should be able to read system files, but should most definitely be blocked from writing outside its defined area.

The point is that BOINC is allowed to download and execute binaries from the projects. I don't think it's ever happened (yet!), but a project could be hacked or go rogue, and start distributing malware. That shouldn't be allowed to escape into the host operating environment.

I fully agree with you. I'm absolutely not advocating against separation, I'm only thinking about this particular systemd feature, separating a service's /tmp and /var/tmp from the rest of the system. There must be a reason behind this feature existing but I can't think of it. Does it apply here or did someone just use all available security features without noticing it affects functionality? I can't judge that. Besides, it's only a theory so far.

BOINC should be able to read system files

As far as everybody is able.

but should most definitely be blocked from writing outside its defined area

Is there a defined area or are we seeing a corner case of a possible definition?

but should most definitely be blocked from writing outside its defined area

Is there a defined area or are we seeing a corner case of a possible definition?

By that wording, I was meaning to refer primarily to the BOINC data folder structure, where most writing takes place. BOINC writes in other places too - offhand, the sticky GUI configurations in the user's home folder (hidden), the GUI lock file, and maybe more. But these are not areas where an executable file could end up.

Edit for clarity: the boinc client writes in the data folder, and so far as I know, nowhere else. The boinc manager writes in the user folders - because the user launches and runs it. The boinc installer will need to write in the system areas, and will require administrative elevation to do so.

By that wording, I was meaning to refer primarily to the BOINC data folder structure, where most writing takes place.

Yes, that's the obvious place. What's not so easy to think of is the exceptions.

BOINC writes in other places too - offhand, the sticky GUI configurations in the user's home folder (hidden), the GUI lock file

Oh, just noticed your edit, so no comment necessary here.

and maybe more

Few words hiding many questions. When, where, why? Acceptable or not? What are the options? I'm not asking you to answer these questions but be aware that they need answering to make a good decision. Obviously I'm thinking of /tmp here, among possible other places.

But these are not areas where an executable file could end up.

There I disagree. I take it you mean to say those particular files you're thinking of aren't executables, but if BOINC or someone else can write at all they can write anything.

... but if BOINC or someone else can write at all they can write anything.

The client (and only the client) is designed to download external files, write them to disk, and as you say, anything is possible. High security is needed.

The manager doesn't download anything, and only writes its own configuration settings. For that to become a malicious executable, somebody would have to persuade you to download a spoof version of BOINC. That's probably outside the scope of this conversation.

The installer is probably the most dangerous of all, but you have to explicitly authorise it. That's why the BOINC developers have always resisted the siren voices that call for an auto-update mechanism.

The client (and only the client) is designed to download external files, write them to disk, and as you say, anything is possible. High security is needed.

Not to forget the science applications, being the client's children, can do the same. As far as I know there's even applications designed to download external code, potentially not under control of the project, and execute it. Yes, anything is possible. And then there's still the potential gap between design and reality.

The manager doesn't download anything, and only writes its own configuration settings. For that to become a malicious executable, somebody would have to persuade you to download a spoof version of BOINC.

Even the genuine manager can make you do things you're not prepared for and probably wouldn't want. It allows you to open links provided by the projects which could trick you into visiting crafted sites. And it can even run external code. Recently there was an issue with Rosetta@Home where a project notice opened a YouTube video without user interaction. Unintentionally in that case but it shows what is possible.

The installer is probably the most dangerous of all, but you have to explicitly authorise it. That's why the BOINC developers have always resisted the siren voices that call for an auto-update mechanism.

On Linux there is no separate installer binary, the system-wide package management is used under control of the boinc package. I have to admit that I routinely authorise that without further checks, that's effectively pretty much auto-update. At least it has to be triggered by a known source.

Presumably the Rosetta notice invoked a video player app already present on your computer, and passed it a url to use as the video data source? In that case, security is the responsibility of the video player app, not of BOINC.

The video may very well be irritating, but it shouldn't be dangerous (in the malware sense).

Um did anyone find a resolution to my complaint? To my eyes it doesn't appear so and looks like the thread got a bit sidetracked? Just wondering what the status is and what if anything I should do? Thanks... Marc C....

---

Marc Chamberlin

Computers: the final frontier. These are the voyages of the user Marc.
His mission: to explore strange new hardware. To seek out new software and new applications.
To boldly go where no Marc has gone before!

I think the feeling was that it's specific to your variety of Linux, which means that you need to take it up with who ever maintains BOINC for that.