[sane-devel] Sandboxing scanner applications

[Bastien Nocera]

On Fri, 2020-09-18 at 19:49 +0300, Alexander Pevzner wrote:
> On 9/18/20 6:44 PM, Bastien Nocera wrote:
> 
> > 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.
> 
> Currently, to print a document, application (with a help of libcups) 
> connects to the CUPS server via TCP or AF_UNIX socket, creates print 
> job, using IPP protocol.
> 
> AFAIK, there is no implementation of the printing infrastructure for 
> Linux, that sends document to be printed via D-Bus.

Both Qt and GTK have print operations that use D-Bus to use the portal
implementations available for different desktops.

GTK portal "server" side (running outside the sandbox):
https://github.com/flatpak/xdg-desktop-portal-gtk/blob/master/src/print.c

Client side:
https://developer.gnome.org/gtk3/stable/gtk3-High-level-Printing-API.html

> If application, that wants to print (say, Firefox) runs in one
> sandbox, 
> and print server runs in another sandbox, they still can use existent
> socket-based infrastructure for communication, and reimplementing
> this 
> infrastructure on a top of D-Bus requires a lot of effort.

Firefox already supports using GtkPrintOperation to print using the
portal, look for nsFlatpakPrintPortal:
https://searchfox.org/mozilla-central/source/widget/gtk/nsPrintDialogGTK.cpp#570

The print portal is not as powerful as talking directly to CUPS to
print, but it's better than having all the apps be on the network just
to be able to print something.

> 
> And of we can use socket-based communication for printing, why not
> use 
> it for scanning as well?

Well, I just showed that you can't. Again, sandboxed applications
should not need to be on the network to be able to print. Or scan.

> 
> > 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.
> 
> Well, the terminology is not quite clear, I agree.
> 
> The idea comes from OpenPrinting group. Till can explain it much
> better, 
> but I'll explain in short.
> 
> To allow sandboxing of print drivers, there were introduced a concept
> of 
> "Printer Applications". Printer application is, essentially, as a
> daemon 
> that communicates with the printer on a hardware-specific way and 
> exposes a standard "IPP Everywhere" printer to the localhost.
> 
> So the CUPS server will not need to be able to print to something
> else 
> that to the "IPP Everywhere" printers, i.e., CUPS will always print
> in a 
> "driverless" mode. All hardware-specific stuff will come as a
> collection 
> of Printer Applications, and these Applications can be sandboxed.
> 
>    
> https://openprinting.github.io/upcoming-technologies/01-printer-application/
> 
> The similar thing in a context of scanning was initially called
> "Printer 
> application for scanning", but because it sounds ugly, the term
> quickly 
> changed to "Scanner Application".
> 
> So "Scanner Application" is not GUI application, but instead a system
> daemon, that exposes a scanner using standard (IPP-scan) protocol.
> 
> > Do you expect user to run this "Scanner Application" manually
> > before
> > they want to scan and import it into an application?
> 
> Of course, no, it will be started among other daemons.
> 
> > 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.
> 
> SANE drivers are essentially are dynamic libraries (shared object in
> ELF 
> terms). Sandboxed shared libraries cannot be accessed from outside of
> the sandbox that owns them.

Right, so we need to have a special driver inside the sandbox that can
talk to a service outside the sandbox.

> I can imagine "mixed" installation, where SANE drivers come
> sandboxed, 
> while simple-scan installed from a usual RPM or DEB package. This 
> "legacy-way" installed simple-scan will not be able to access SANE 
> drivers directly.

But sane _drivers_ aren't sandboxed. The application using the hardware
driver is.

At this point, I don't think that using the IPP Scan protocol is a good
match for sandboxing SANE applications if it requires network access to
work.

If requiring network access for scanner (or printer) access, we
wouldn't already have a printing portal, and we could already use
"saned" and the net plugin for scanners.

So, will it be possible to use IPP scan without using IP, preferably
over D-Bus, so it can be filtered, and authorised, using the existing
portal mechanisms?

Cheers