[cups.development] Kerberos delegation
Michael Sweet
msweet at apple.com
Tue Mar 3 10:28:06 PST 2009
On Mar 3, 2009, at 9:26 AM, Andy Polyakov wrote:
> ...
> One of commonly recognized "good-design" principles for a security
> system is least required privilege. And the question is if
> delegation is
> actually required for cups? Or even, is it appropriate for an
> application to effectively deny a site to exercise more restrictive
> policy for delegating credentials?
Kerberos over HTTP requires credentials that can be delegated and
forwarded.
(its part of the spec that we have to follow)
> Let's consider web-based administration to start with. As of now the
> only way to get it working is to ensure that administrator gets
> forwardable TGT and configures his/her browser for delegation (in
> Mozilla case ensures that cups server is listed in
> network.negotiate-auth.[trusted|delegation]-uris)... But for what
> purpose exactly? What happens is following: cupsd saves forwarded TGT;
> forks a cgi program which connects back to cupsd; with the help of
> previously saved forwarded TGT the cgi program pulls a ticket to cupsd
> server and authenticates itself... Does it really have to be that way?
> Couldn't cupsd recognize own descendant and assume initiating client's
> identity? And thus eliminate requirement for delegation?
The web interface CGI programs use local certificate authentication
instead of Kerberos - when you access a page that needs Kerberos, the
browser provides the credentials to cupsd, which "saves" them with the
certificate for the CGI program.
> Moving on to printing. As it is now *if* you ought to talk to cupsd on
> localhost, then your host has to have proper keytab, even if your
> computer has no locally attached printers. But maintaining hundreds of
> keytabs is no fun and sometimes is simply impossible (think
> self-administered computers). Three possibilities: a) instead of
> talking
> to local cupsd talk directly to central server that delivers printouts
> to all the printers (for reference, currently deployed scenario at our
> site);
This is something we are looking at for CUPS 1.5.
> b) have local cupsd forward client requests with HTTP 3xx
> redirection code (would it require cups modification, right?);
That would require a CUPS change on all clients and has security
issues of its own when the client does not use Expect:. In addition,
I do not believe that Windows supports the 307 redirects that would be
needed for POSTs.
> c) given
> that local cupsd is privileged it could access user ticket cache
> without
> requiring delegation (doesn't require client modification). In these
> cases delegation would be required only if back-end would require
> authentication, let's say back-end was to talk to Windows server.
That won't work without writing a whole new Kerberos implementation
(i.e. a replacement for MIT or Heimdal) since even though you can read
the user ticket cache you can't ask for new tickets from that cache
(which is what would be needed).
> Another related issue here (actually of larger interest in our
> context)
> is printout delivered through samba running on cupsd server. As samba
> can't make clients provide forwarded TGT, authentication between samba
> and cupsd is doomed to fail. Unless of course one does something...
SMB-based printing is always going to be problematic due to the
fundamental limitations of the protocol. Printing is an afterthought
with SMB and Windows has no notion of server proxies - you always talk
directly to the destination server from the user session. So, if you
require Kerberos authentication in CUPS you can't use Samba for
printing, only IPP (https://server:631/printers/printername).
________________________________________
Michael R Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cups.org/pipermail/cups-devel/attachments/20090303/f540d148/attachment.html>
More information about the cups-devel
mailing list