[Printing-architecture] IPP-over-USB and Printer Applications: DNS-SD-advertise localhost:PORT a security problem?
skau at chromium.org
Sat Dec 1 01:52:24 UTC 2018
I think that using cupsd as the gateway to all Printer Applications
(including IPPUSB) is the best approach. However, I would like cupsd to be
the only application that can communicate with Printer Applications. It is
also convenient if discovery continues to happen using cupsEnumDests and
the advertisement protocol shouldn't be terribly important to client
We could perform discovery over a domain socket, even continuing to use
DNS-SD if we register the Printer Applications with CUPS. We could still
have ephemeral printers in this case, as CUPS could rediscover the printer
but would need some knowledge of which Printer Application is supposed to
handle the request. Since we can only map one uri per domain socket, this
would be problematic. So we would need a dynamic allocation scheme which
is potentially complicated. However, would it be possible to host multiple
printers on the same URI distinguishing with some other attribute?
Possibly printer-uuid? IPP System service specifies a printer-id attribute
that can identify printers at a given endpoint. As far as I can tell, the
primary advantage to using TCP over localhost is the presence of port
On Mon, Nov 26, 2018 at 5:47 AM Michael Sweet <msweet at apple.com> wrote:
> 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>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Printing-architecture