[sane-devel] Sandboxing scanner applications

[Bastien Nocera]

On Fri, 2020-09-18 at 19:54 +0200, Till Kamppeter wrote:
> 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).

That's pretty much the exact same thing as running saned on the host
and using the "net" driver. It still requires punching a hole in the
sandbox which shouldn't be necessary.

> 
> > 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.

You're describing Snap's static permissions. I'm talking about the
dynamic permissions that portals offer, and that Snap applications are
slowly starting to use.

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

Neither does Flatpak... Unless you want a sandboxing that actually does
something. If you need to punch a hole to access raw USB devices
without authorisation (not authentication), or access the network at
will, it's not good sandboxing.

We're starting to go in circles here. Let me sum things up.

* Things we can do now:
- run a specially configured version of saned on the host
- use the "net" driver for SANE application inside the sandbox,
connecting to the loopback

Pros:
- exists now
- works with all the SANE applications

Cons:
- requires punching a hole for the network in the sandbox
- no authorisation for using the scanner

* What your project is, from my understanding:
- run an IPP scan server ("Scanner Application") on the host
- use the airscan sane driver inside the sandbox

Pros:
- works with all the SANE applications

Cons:
- doesn't work yet
- would require punching a hole for the network in the sandbox

* What my original idea was:
- run a D-Bus-y version of saned on the host
- use a new "dbus" driver inside the apps

Pros:
- works with all the SANE applications
- would allow users to block scanner access if necessary
- doesn't require network access

Cons:
- doesn't exist yet

Does that make it clearer?

> 
>     Till