Sandboxing services

Goverp · Advocate Joined: 07 Mar 2007 Posts: 2261

Reading about another supply chain corruption on slashdot got me thinking about languagetool and similar services. I commented on ebuilds for languagetool in another topic, it's a Java application, and the ebuild just unpacks a zipfile. I'm using languagetool as an example here, I've have no reason to suggest it's been compromised, it's just that I'm familiar with it. The unpacked Java application runs as a service, in my case managed by OpenRc.

Having it as a service allows one level of protection - it runs under a different userid with no privileges and member of no groups, so it shouldn't be able to see anything in my user address space/disk space, so I'm safe from it reading my emails, key files, browser cache, right? Except what it does is, when enabled, scan EVERY file opened using any tool where I enable it, specifically libreoffice. Ah, so it might well read letters to or from my bank, investment brokers, etc.

So what's to stop a service like this, or say ClamAV (which on my setup reads all emails) from sending interesting tidbits somewhere? Neddy Seagoon says to ensure your firewall blocks outbound traffic you don't expect, but I'm not sure that's enough to stop say a Java app using REST protocols from sending data to a command-and-control centre masquerading as a web site using https on port 80.

I read a couple of articles recently (though I forget the details), one about sandboxing apps to limit specific abilities, and one about using kernel LSMs to limit specific apps (IIRC). So, in this particular, case I want to stop OpenRc services from using the network. Thoughts please.
_________________
Greybeard

szatox · Advocate Joined: 27 Aug 2013 Posts: 3657

So, this service is supposed to do all its work locally, right? It doesn't use any cloud api for assitance?
It might actually be a valid use case for stuff like docker. Pull an already made image, and then don't let it talk to the internet at all... But there is an easy homemade option too:

> Neddy Seagoon says to ensure your firewall blocks outbound traffic you don't expect, but I'm not sure that's enough to stop say a Java app using REST protocols from sending data to a command-and-control centre masquerading as a web site using https on port 80.

I think that's the part you got wrong. You don't block it because it goes to "a not website". You block it, because it originates from an app that is not supposed to be talking to strangers.
And since it runs as a different user, you can do something like
iptables -I OUTPUT -j REJECT -m owner --uid-owner <service user>

or even better, create a netclient group you give to yourself and portage, ACCEPT traffic that matches it, and set output policy to DROP. It would protect you from mishaps like a missing iptables module or forgetting to save your new rules unintentionally opening the flood gates again, but it would also be a more involved setup.
You can even follow up with a netserver group for accepting incoming traffic too, if you run a service which should respond to request but has no business initiating conversations.

Oh, BTW, Gentoo default umask allows anyone to enter directories and read files. I hope you remembered to close that gap.
_________________
Make Computing Fun Again