[sane-devel] Sandboxing scanner applications

[Till Kamppeter]

On 18/09/2020 17:01, 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?
> 

Yes. But if the scanner is a local USB scanner for example, its Scanner 
Application would only advertise itself on localhost (loopback 
interface) and take jobs from localhost, so scan jobs stay on the same 
machine and remote machines do not see the scanner and also cannot scan 
the document in it. Sharing to other machines has to be configured 
withing the Scanner Application (the daemon which is the scanner driver).

> 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?
> 
> Is there code somewhere for the "Scanner Applications", that IPP scan
> server that would talk to the actual servers?
> 

There is already a working example of a Printer Application:

https://github.com/michaelrsweet/hp-printer-app/

Another example is in the PAPPL project:

https://github.com/michaelrsweet/pappl/

Access and configuration for Scanner Applications works the same way.

Work on Scanner Applications has started here:

https://github.com/Abhik1998/pappl/

> 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.
> 
> This is how you'd get a file chooser, running outside the sandbox, and
> that would pass back the file's data inside the sandbox if the user
> clicks to say that they want to open this file, or how a screenshot
> could be shared with the application:
> https://blogs.gnome.org/mclasen/files/2016/07/portal-test2.png

OK, in Snap we have the interfaces, so one can make Snap connect to 
system resources like network, usb-raw, avahi (this is not full network, 
only avahi), cups (printing only), cups-control (create/modify queues), 
.. Snaps can also define an interface, a so called slot and another snap 
can connect to it by a so-called plug, so one has a communication 
between two Snaps. The sandboxing of Snaps goes mainly via AppArmor and 
the interfaces introduce AppArmor rules for selected permissions.

So Snap does not need to re-design the formerly file- and network-based 
operating system into a D-Bus-only system.

    Till