[Printing-architecture] IPP-over-USB and Printer Applications: DNS-SD-advertise localhost:PORT a security problem?

[Michael Sweet]

Sean,

The model used by the current release of CUPS is that applications discover printers via DNS-SD and then ask cupsd to communicate with the printer on localhost - we avoid direct network access whenever possible since other OS's (macOS in particular) use application sandboxing and "entitlements" to limit what an application can do, including creating arbitrary network connections.

To do the same thing with domain sockets, we'd need to invent yet another backend and discovery mechanism with a dynamic domain socket allocation scheme, have each application (through libcups) communicate with the printer and create a (permanent) print queue with a generated PPD, and then maintain that through the major CUPS architectural changes that are to come.

I'm not sure if any of this helps you on ChromeOS at all, but personally I think that using cupsd as the gateway to the IPPUSB printer is the better long-term approach (and we'd welcome any bug reports/pull requests if you find instances of the CUPS API talking to a printer directly without the application opening an explicit connection to it...)


> On Nov 21, 2018, at 5:41 PM, Sean Kau <skau at chromium.org> wrote:
> 
> Thanks Till.
> 
> To clarify, we don't consider advertisement on localhost to be a security problem.  But in the spirit of reducing our attack surface we prefer to moderate communication between processes.  Because of this, we prefer not to communicate over the loopback interface.  Instead, we currently use Unix Domain Sockets since we can control access to those using standard user and group permissions.
> 
> Sean Kau
> 
> On Wed, Nov 21, 2018 at 2:26 PM Till Kamppeter <till.kamppeter at gmail.com> wrote:
> Hi,
> 
> I talked with Sean Kau and David Valleau from Chrome OS (CCed) about the 
> implementation of IPP-over-USB with ippusbxd in Chrome OS. Sean told
> 
> ----------
> Using DNS-SD on localhost doesn't fit our security model as we don't 
> want to allow arbitrary processes to talk to each other.
> ----------
> 
> This would mean that we cannot implement IPP-over-USB and Printer 
> Applications as innitially thought out. They are supposed to make the 
> printer available as
> 
> ipp://localhost:PORT/ipp/print
> 
> with PORT varying so that there can be several devices connected to the 
> same machine (and CUPS running in addition). For CUPS (or the printing 
> system in general) automatically discovering the devices and creating 
> print queues the Printer Applications (and ippusbxd) are supposed to 
> advertise themselves via DNS-SD.
> 
> This would mean (local-only) advertising of localhost via DNS-SD, which 
> Sean considers a security problem. Is this actually a security problem? 
> If so, how should Printer Applications (and ippusbxd) actually work?
> 
>     Till
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

_________________________________________________________
Michael Sweet, Senior Printing System Engineer