A secure user

Anonymous anonymous at easysw.com
Thu Apr 20 07:28:30 PDT 2006


> Yes, but right now we don't even do that!  You'll find this
> documented in the Server Security help file in CUPS 1.2, BTW...

Sure, I know, I'm talking about hacking it in.

> > Are there browsers that support IPP printing, or can cert auth
> > be done in say, adding a Windows IPP printer? Again, though,
> > I'd like to avoid client-side changes as much as possible.
>
> You can't avoid client-side changes - *something* has to know to
> send that certificate for the server to use.

Well, honestly, for a certain kind of configuration, I think I
can avoid client side changes, mainly thanks to the ipp backend
which already supports https:// . I was able to do this with the
encrypted ident, and I think I can do it for cert auth.

It amounts to using the local cups server basically as a proxy:

user - domain sock -> local cupsd - SSL verified conn -> master cupsd

The domain sock isn't spoofable AFAIK. The local cups server then
uses the ipp backend with a client cert to connect to the master
who verifies the connection and considers this IPP user authenticated.

Here's where I see the hacks needing to be done:

    - DomainSockAuth type for local cupsd
    - Hack to IPP backend adding https://host?cert=/path/to/cert.pem
    - Hack to master cupsd to allow certified auth based on local
      cupsd cert
    - Exception for localhost printing for e.g. samba printing

Do you see a hole in this scenario or a place where client side
cert support must be added?

> AFAIK, no browser supports IPP printing directly; some do indirectly
> via toolkit support of CUPS.  I don't know if Windows allows you to
> provide a user certificate that is used when negotiating a SSL or
> TLS session.
>
> I'm looking at using certificates in a more general sense -
> eliminating the need for a username/password challenge in the web
> interface or any other HTTP access, which includes IPP operations.
> Just doing it for a few specific paths will be a hack and will
> probably be more difficult than the general solution (where hooks
> already exist for this kind of thing...)

I don't see why this couldn't be added now as a stopgap measure
until certs are fully supported. Even if certs are fully supported,
I don't relish the idea of issuing one for all my users :->

> Regardless, a STR will help us track this, including any code you
> may want to contribute...

Ok.

Jim




More information about the cups mailing list