[sane-devel] Sandboxing scanner applications

[Bastien Nocera]

On Fri, 2020-09-18 at 20:41 +0200, Till Kamppeter wrote:
> On 18/09/2020 17:44, Bastien Nocera wrote:
> > > Neither me not Till seems to be familiar with Flatpak, so I would
> > > appreciate if provide a bit more detailed explanation of how the
> > > things
> > > expected to work.
> > 
> > This isn't so much about Flatpak, but about portals that Snap also
> > uses
> > to implement sandboxing, even if the majority of Snaps don't
> > implement
> > any kind of sandboxing (AFAIK).
> > 
> 
> Do you mean with this "majority of Snaps" the classic Snaps? This is
> a 
> type of Snaps which is less restricted and interacts more with the 
> system. Not really recommended. The full sandboxing you get with
> fully 
> restricted standard Snaps. My CUPS Snap 
> (https://github.com/OpenPrinting/cups-snap) is one of these and is 
> designed for communicating with clients (apps which print or which 
> configure the print environment) and Printer Applications (drivers as
> IPP-printer-emulating daemon) both in fully restricted Snaps by 
> themselves. So one could get an all-Snap OS distribution with snapped
> appplications, snapped CUPS, and snapped printer drivers.
> Implementation 
> of the needed system interfaces in snapd is currently ongoing. See
> the 
> links in my monthly news posts on  
> https://openprinting.github.io/news/.
> 
> > A portal is a D-Bus service running outside the sandbox offering
> > services to the sandbox application, such as file chooser,
> > printing,
> > screenshots, localisation, etc. Sandboxed applications call a well-
> > known D-Bus service, and wait for an answer. The D-Bus service asks
> > the
> > user about the resource to be shared, gives it back to the
> > application.
> > 
> > The application doesn't need network access to access a remote
> > printer,
> > for example, as the D-Bus service outside the sandbox is the one
> > contacting the printer. Ditto for files access, etc.
> > 
> 
> So communication of a flatpaked application is D-Bus only?

It's the best way to avoid an application having more access to the
network and other resources than it should. A lot of applications right
now still punch holes for specific local services, or for network
access, because it's still better to get some sandboxing than none at
all. It's not how we want to go forward though.

> 
> Does it also mean that only user applications (like LibreOffice, 
> Firefox, Darktable, ...) will get flatpaked? And system components
> (like 
> CUPS, network-manager, ...) will not get sandboxed in Flatpak
> packages?
> 
> Snap allows all-Snap OS distributions.

This really isn't relevant to what I wanted to discuss.

I'm not interested in whether the host side will be sandboxed and how
(on non-Snap, systemd can already solve both the distribution and the
sandboxing problems), but of how the end-user application, an
application that's possibly malicious, or with security issues.

>From the discussions here, it looks like using IPP over an AF_UNIX
socket, including authorisation, device discovery, etc. would be just
about as much work as creating a new host daemon and a driver for the
sandboxed app, so that's probably the way I'll go. That host daemon can
probably sit on top of the "Scanner Application" if it needs to, at
some point in the future.

The question is which of the technologies I mentioned in my original e-
mail would have a better chance of landing upstream in the sane
repositories.

Cheers

> 
>     Till