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

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

[Till Kamppeter]

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

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

[Sean Kau]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1980 bytes --]

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

[Johannes Meixner]

Hello,

On Nov 21 23:26 Till Kamppeter wrote (excerpt):
> ... advertising ... via DNS-SD ... security problem

in general regarding DNS-SD and security see also
https://github.com/apple/cups/issues/5011

I think (but I know nothing at all about the details here)
advertising a locally connected USB printer via any method
(e.g. via DNS-SD) only on the local host should not result
that more users can access the USB printer than before.

Traditionally the device node of a locally connected USB printer
gets by default appropriate traditional Unix permissions so that
the user who runs the CUPS backend (usually user 'lp' group 'lp')
can access the USB printer (usually via the group 'lp').
This means local USB printer access is not permitted for each
individual local user (e.g. via appropriate group settings).
Direct USB printer access is not permitted for normal users.
For normal users USB printer access is only permitted
indirectly via CUPS.

Another crucial point with any kind of networking advertisments
of local USB printers is that the devices must not accidentally
become accessible to any remote user.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

Re: [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@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@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@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

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

[Sean Kau]

[-- Attachment #1: Type: text/plain, Size: 4508 bytes --]

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

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

Sean

On Mon, Nov 26, 2018 at 5:47 AM Michael Sweet <msweet@apple.com> wrote:

> 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@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@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@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
>

-- 
Sean Kau

[-- Attachment #2: Type: text/html, Size: 5585 bytes --]

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

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

Sean,

> On Nov 30, 2018, at 8:52 PM, Sean Kau <skau@chromium.org> wrote:
> ...
> We could perform discovery over a domain socket, even continuing to use DNS-SD if we register the

DNS-SD discovery happens through Avahi, which uses DBUS as its communications mechanism.  If the discovered printer has no equivalent CUPS queue, libcups will use a CUPS-Create-Local-Printer request to ask cupsd to resolve and talk to the printer to setup a (temporary) local print queue, and thereafter the client application only ever communicates with cupsd unless it explicitly requests a connection to the printer itself (CUPS_DEST_FLAGS_DEVICE passed to cupsConnectDest) - that would be used by a management application OR by a print dialog wanting to show the currently loaded media. Longer term we would like to be able to relay the currently loaded media via cupsd as well, but that is problematic from a performance perspective...

> ...
> printers at a given endpoint.  As far as I can tell, the primary advantage to using TCP over localhost is the presence of port numbers.

No, it is because the IPP and IPPS URI schemes are based on HTTP and HTTPS, which only recognize Internet Protocol addresses and DNS-style names.  The use of the domain socket by cupsd is non-standard, and even the URIs you pass to cupsd must still use "localhost" when communicating over the domain socket since you can't embed a domain socket filename in the URI without causing a lot of problems...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer


[-- Attachment #2: Type: text/html, Size: 4558 bytes --]