[sane-devel] Sandboxing scanner applications

[Bastien Nocera]

On Fri, 2020-09-18 at 18:22 +0300, Alexander Pevzner wrote:
> On 9/18/20 6:01 PM, Bastien Nocera wrote:
> > So the application inside the sandbox would ship with sane-airscan
> > backend, and use this protocol, over the network, to communicate
> > with
> > the fake "airscan" scanner running outside the sandbox, right?
> 
> Over loopback in most cases.
> 
> > Having every scanner application access the network is going to be
> > a
> > problem, much like having to punch of network hole to get full CUPS
> > access is a problem right now. Is there going to be another
> > transport?
> 
> AFAIK, loobback is not usually protected by firewall.
> 
> Using TCP/IP stack instead of AF_UNIX sockets has an advantage to
> allow 
> using of Avahi daemon for local discovery of present devices. With 
> alternative transport, some alternative discovery method should be 
> designed and implemented.

We don't want applications to require network access to access a
scanner. There's absolutely no reason why, say, "Simple Scan" needs to
access the network, which it would need to if you wanted it to be able
to access the loopback interface.

> > Note, I said authorisation, not authentication. "Authorisation" is
> > when
> > the user chooses to allow or disallow access by the application.
> > It's
> > the method, coupled with user intent, used by Flatpak portals to
> > check
> > whether an application is allowed to use a particular resource
> > outside
> > the sandbox.
> 
> 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).

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.

> 
> 1. There is a "Scanner Application", backed by SANE stack, which has
> a 
> physical access to the scanner, running in the isolated Flatpack
> environment

Is "Scanner Application" a GUI app, a plugin, a network server? Is this
what's going to offer the IPP Scan extension to apps? I must say I'm
utterly confused by the name.

Do you expect user to run this "Scanner Application" manually before
they want to scan and import it into an application?

> 2. There is some Client program, that wants to scan (for example,
> xsane 
> or simple-scan, or even libreoffice). It may or may not be running in
> a 
> sandbox

This client program would most likely run inside a sandbox. If it
didn't, it would be able to access the local scanner in the same way it
does now.

> 
> Who and in which terms will allow access of (2) to (1)?

I don't think that we should need (1) to implement sandboxing of
scanning applications that use the SANE API.