Didier, Indeed, we can add additional directory checks to the "simple" fix, or for purposes of the Debian packages just disable certain directives if they should not be configured from their defaults.
WRT setting SystemGroup, that /is/ a valid configuration change that some sites make; disabling that directive might break some sites, but at least they can tweak their policy sections to grant printer admin rights as a workaround? Seems like maybe the simplest fix is to disable the problematic directives (just use defaults); sites that need to change from the defaults can install their own versions of the cups packages. Thoughts? Sent from my iPad On 2012-11-28, at 4:54 AM, Didier 'OdyX' Raboud <o...@debian.org> wrote: > Le mercredi, 28 novembre 2012 05.38:58, Michael Sweet a écrit : >> After looking at this patch in detail, it doesn't actually prevent users in >> the lpadmin group from modifying cupsd.conf and performing the specified >> privilege escalation. >> >> An alternate fix for cups-1.5 and earlier that specifically addresses the >> reported problem by requiring the log files to reside in CUPS_LOGDIR: > > Indeed, thanks. BUT, as far as I can test, this patch lets some potential > attacks open, such as setting DocumentRoot to /etc (then access > http://localhost:631/shadow …). With some imagination, you could set > SystemGroup to "lpadmin other-group", granting cups administration rights to > "other-group", etc. > > At least DocumentRoot has to be constrained to stay what the package says it > is IMHO. > > Cheers, > > OdyX -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
