<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 3, 2009, at 9:26 AM, Andy Polyakov wrote:</div><blockquote type="cite"><font class="Apple-style-span" color="#000000">...</font></blockquote><blockquote type="cite">One of commonly recognized "good-design" principles for a security<br>system is least required privilege. And the question is if delegation is<br>actually required for cups? Or even, is it appropriate for an<br>application to effectively deny a site to exercise more restrictive<br>policy for delegating credentials?<br></blockquote><div><br></div>Kerberos over HTTP requires credentials that can be delegated and forwarded.</div><div>(its part of the spec that we have to follow)</div><div><br></div><div><blockquote type="cite">Let's consider web-based administration to start with. As of now the<br>only way to get it working is to ensure that administrator gets<br>forwardable TGT and configures his/her browser for delegation (in<br>Mozilla case ensures that cups server is listed in<br>network.negotiate-auth.[trusted|delegation]-uris)... But for what<br>purpose exactly? What happens is following: cupsd saves forwarded TGT;<br>forks a cgi program which connects back to cupsd; with the help of<br>previously saved forwarded TGT the cgi program pulls a ticket to cupsd<br>server and authenticates itself... Does it really have to be that way?<br>Couldn't cupsd recognize own descendant and assume initiating client's<br>identity? And thus eliminate requirement for delegation?<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite">Moving on to printing. As it is now *if* you ought to talk to cupsd on<br>localhost, then your host has to have proper keytab, even if your<br>computer has no locally attached printers. But maintaining hundreds of<br>keytabs is no fun and sometimes is simply impossible (think<br>self-administered computers). Three possibilities: a) instead of talking<br>to local cupsd talk directly to central server that delivers printouts<br>to all the printers (for reference, currently deployed scenario at our<br>site);</blockquote><div><br></div>This is something we are looking at for CUPS 1.5.</div><div><br><blockquote type="cite"> b) have local cupsd forward client requests with HTTP 3xx<br>redirection code (would it require cups modification, right?);</blockquote><div><br></div><div>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.</div><br><blockquote type="cite"> c) given<br>that local cupsd is privileged it could access user ticket cache without<br>requiring delegation (doesn't require client modification). In these<br>cases delegation would be required only if back-end would require<br>authentication, let's say back-end was to talk to Windows server.<br></blockquote><div><br></div><div>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).</div><div><br></div></div><div><blockquote type="cite">Another related issue here (actually of larger interest in our context)<br>is printout delivered through samba running on cupsd server. As samba<br>can't make clients provide forwarded TGT, authentication between samba<br>and cupsd is doomed to fail. Unless of course one does something...<br></blockquote><div><br></div><div>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 (<a href="https://server:631/printers/printername">https://server:631/printers/printername</a>).</div><div><br></div></div><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>________________________________________</div><div>Michael R Sweet, Senior Printing System Engineer</div></div></div></span></span>
</div>
<br></body></html>