search

michaelrsweet / pappl

PAPPL - Printer Application Framework
https://www.msweet.org/pappl
Apache License 2.0
309 stars 49 forks source link

libpappl writes TLS certificates into hard-coded /etc/cups/ssl/ directory #144

Closed tillkamppeter closed 3 years ago

tillkamppeter commented 3 years ago

I want to snap the PostScript Printer Application in a way that after installing the Snap the server gets automatically started. For this I create an app with daemon: simple in snapcraft.yaml:

apps:
  ps-printer-app-server:
    command: scripts/run-ps-printer-app -o log-level=debug -o log-file=/var/snap/ps-printer-app/common/ps-printer-app.log server
    daemon: simple
    plugs: [avahi-control, home, log-observe, network, network-bind, network-manager, raw-usb]
  ps-printer-app:
    command: scripts/run-ps-printer-app
    plugs: [avahi-control, home, log-observe, network, network-bind, network-manager, raw-usb]

The scripts/run-ps-printer-app sets some environment variables to tell the Printer Application where to put its files and then starts ps-printer-app itself, passing through all command line arguments.

This makes the server instance of the Printer Application running as root, and the TLS functions in pappl/system-webif.c try to put the certificates into /etc/cups/ssl/ which is not accessible in the Snap. The Snap would need its own place (usually somewhere in /var/snap/ps-printer-app/current/).

There is no way to change this at build time via ./configure option nor at run time by an environment variable or command line option.

michaelrsweet commented 3 years ago

@tillkamppeter There is no way to override this in CUPS - it is hardcoded to look in /etc/cups/ssl for root and ~/.cups.ssl for ordinary users.

tillkamppeter commented 3 years ago

On of the intentions of the Printer Application concept is to have the Printer Application running in one sandbox/Snap, emulating a network IPP printer and CUPS or any other client software running in another sandbox/Snap. Inside a Snap there is no access to /etc/cups/, the files created at run time (like such certificates) have to go to /var/snap/SNAPNAME/current/ and subdirectories.

I assume that the certificates do not have to be shared between server (the Printer Application) and client (CUPS, and application which wants to print, or a web browser for the admin interface) as a real hardware IPP printer also does not share certificates in a file system, its only communication channels are the IPP connection for administration and for printing and DNS-SD for discovery.

Inside a Snap an auto-started daemon is usually run as root (then PAPPL forces the /etc/cups/ssl/ for the certificates), as the installed Snap is belonging to the system, not to one of the users. The confinement of the Snap is providing the security for the root-running process not affecting the rest of the system.

I could run the server process as a system user (then the certificates go into the home directory of the system user which is somewhere in the Snap's runtime file system) inside the Snap, but this restricts the possibilities of creating printer drivers a lot, many manufacturers will want to have the communication with the printer hardware run as root (proprietary interfaces of specialty printers) and also for a smooth retro-fitting of existing drivers I need the possibility to run the Printer Application inside the Snap as root.

I also hope that you do not expect from every user that in order to be able to print that he manually runs the Printer Application with the server command line argument. He expects that when he gets a Printer Application from the Snap Store that right after installation he has an emulated IPP printer and is able to print on it.

I hope we do not need to make another hole in snapd, the ones for CUPS have taken a year from design until passing Canonical's security team.

Also note that inside the Snap we only use libcups for using some of its functions but not cupsd, so there should not be a big problem to have the certificates in another location.

We need to make the things as easy as possible to make end users accept them, note that consumers started to take photos when Kodak started to develop the film for them, and that end users started to use Linux when distros compiled and packaged the software for them.

michaelrsweet commented 3 years ago

@tillkamppeter The TLS support is part of libcups, NOT cupsd. Since Linux does not provide a system-wide certificate store like Windows or macOS, we had to roll our own and for libcups that meant locating the files in /etc/cups/ssl or ~/.cups/ssl. THERE IS NO PROVISION FOR OTHER DIRECTORIES, and PAPPL is completely unable to change that since there is no CUPS API for doing so.

Conceptually we could update libcups to look for the SNAP environment variables and use those to locate the CUPS certificate directory for root, but that would still mean that every printer application would have its own certificate store and users would have to manage those things separately. For most users that are happy with self-signed certificates, that is probably not an issue, but for enterprise users they will want the ability to side-load CA-signed certificates appropriate to their organization.

Alternately, if Linux adopted a standard (DBUS-based?) X.509 certificate storage API then libcups could use that and the snap environment could allow that for all applications that needed it.