Bug 46943 - adding printer: root password required for console user in wheel group
adding printer: root password required for console user in wheel group
Status: REOPENED
Product: cups-pk-helper
Classification: Unclassified
Component: General
unspecified
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Marek Kasik
http://ponzo.net/PolKit-printer/
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-03 15:27 UTC by Scott Doty
Modified: 2015-05-11 14:59 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Change default policies (2.66 KB, patch)
2012-03-13 03:45 UTC, Vincent Untz
Details | Splinter Review
Do not use "all-edit" for jobs owned by someone else (1.96 KB, patch)
2012-03-13 03:46 UTC, Vincent Untz
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Doty 2012-03-03 15:27:25 UTC
This bug would appear to be the one Linus Torvalds was gretching about w/respect to his daughter adding a printer at school.

While checking this, I was logged in on the console, in an Xfce session, with my primary username on the system (which was, and is in the "wheel" group).

See screenshots of dialogues I encountered:

http://ponzo.net/PolKit-printer/

 -Scott
Comment 1 Scott Doty 2012-03-03 15:28:12 UTC
(setting platform, adding URL).
Comment 2 David Zeuthen (not reading bugmail) 2012-03-03 16:52:47 UTC
Sure, that's bad and agree I with Torvalds it's inappropriate to require administrator authentication etc... but it's not a polkit problem since polkit is only a toolkit (and a toolkit can be used correctly or incorrectly etc). You should file a bug against the mechanism in question - looks like it's this project

 http://cgit.freedesktop.org/cups-pk-helper/

Closing as NOTOURBUG. Thanks.
Comment 3 Scott Doty 2012-03-03 17:03:55 UTC
Thanks bub for not editing the ticket to send it to the correct project.  It makes so much more sense for you to say "not my job" and have me refile the bug.

Also, today is opposite day.
Comment 4 Vincent Untz 2012-03-04 03:19:24 UTC
It's really not a bug: it depends on the default policies for the various actions (see the screenshots). The policies we ship upstream are restrictive by default for this (to not surprise distributors), and it's up to distributions to choose the ones they want.
Comment 5 David Zeuthen (not reading bugmail) 2012-03-04 08:36:30 UTC
(In reply to comment #4)
> It's really not a bug: it depends on the default policies for the various
> actions (see the screenshots). The policies we ship upstream are restrictive by
> default for this (to not surprise distributors), and it's up to distributions
> to choose the ones they want.

That's a terrible approach ... upstreams need to lead, not just wash their hands saying "oh, but our defaults were secure" when you know, just as well as I, that your defaults are completely broken and unusable. You need to man up.
Comment 6 Scott Doty 2012-03-04 15:34:05 UTC
This is the second time in two years that this has been brought up, and ignored.  Let's not let it slip through the cracks this time, but make sure we get this straightened out.

Can you please put me in touch with whomever is in charge of setting this policy?  I would like to exchange correspondence with the group or committee.

Or if you prefer, please point them at this bug, which I've reopened.

It should be noted that in virtually all cases, the user can contact network printers on their own.  It is actually less secure to ask for the root password for this case, because it isn't needed whatsoever to accomplish the task at hand.  Thus, asking for the password does nothing but expose the plaintext root password to the system, which is an opportunity to intercept the root password

Thank you for your time, especially on a weekend. :)

 -Scott
Comment 7 Miloslav Trmac 2012-03-04 16:12:10 UTC
(In reply to comment #6)
> It should be noted that in virtually all cases, the user can contact network
> printers on their own.  It is actually less secure to ask for the root password
> for this case, because it isn't needed whatsoever to accomplish the task at
> hand.

Given the current architecture, root access or other authentication to cups _is_ required.  I'm fine with opening this up to the wheel group, but requiring no authentication for any local user is a bad idea IMO.

I don't know, perhaps it would be possible to have an unprivileged cups acting as a network printer client - however that's something quite different from just stopping asking for passwords.
Comment 8 Scott Doty 2012-03-04 16:30:40 UTC
Nobody said anything about not asking for a user password -- it's the root password that is completely unnecessary for this use case.

The young lady who encountered this was on the console of her own laptop, trying to add a network printer.  Her dad had the root password, she did not.  There is nothing gained by denying her access to network printers in such a case.

I think we both understand why we wouldn't want there to be no password whatsoever -- to prevent trojan activity.  You bring up an interesting idea, though that this could be done with _no_ password disclosed.  Because, really, there is nothing gain in asking for the password, since the user _could_ just use (say) nc to access the printer directly.

But be that as it may, let's put to rest the idea that exposing the root password in this matter is necessary.  What we have is a bug in the policy for this software -- if there are technical reasons why the policy can't be changed, then that forms the technical changes necessary to resolve the bug.

This is broken.  Let's fix it.
Comment 9 Vincent Untz 2012-03-13 03:40:20 UTC
This fell off my radar last week, when bugzilla was down because of a VM migration, sorry.

I understand that other distros don't work the same way as openSUSE when it comes to deciding what the policies are for actions (in openSUSE, the upstream policies don't matter much, as each policy is evaluated by the security team).

So, let's try to get this right. Below, I only consider the allow_active value.

org.opensuse.cupspkhelper.mechanism.server-settings: this can set server settings, so I think this should stay "auth_admin_keep".

org.opensuse.cupspkhelper.mechanism.devices-get: get a list of available devices. I see no reason to require authentication for this. Move to "yes".

org.opensuse.cupspkhelper.mechanism.printer-set-default: just change a default printer. This is not a harmful operation, as this can be reverted easily. Move to "yes".

org.opensuse.cupspkhelper.mechanism.printer-enable: enable/disable a printer. This can be reverted easily. Move to "yes".

org.opensuse.cupspkhelper.mechanism.printer-local-edit, org.opensuse.cupspkhelper.mechanism.printer-remote-edit, org.opensuse.cupspkhelper.mechanism.class-edit: those can involve uploading a PPD file to CUPS, so we need to have some authentication to prevent this happening without the user being aware of the change. Move to "auth_self_keep".

org.opensuse.cupspkhelper.mechanism.job-edit: already set to "yes".

org.opensuse.cupspkhelper.mechanism.job-not-owned-edit: leave as "auth_admin_keep" as this involves data from other users.

org.opensuse.cupspkhelper.mechanism.all-edit: this one is harder, as it's actually a meta action, done the old way. Based on the way we use it, it could be moved to "auth_self_keep". However, we first need to change the code a bit so that it's not used for jobs not owned by the user.

org.opensuse.cupspkhelper.mechanism.printeraddremove: deprecated, leave it away.

What do people think? (cc'ing Marek, as his work on using c-p-h from the control center gives him a good vision of all this)
Comment 10 Vincent Untz 2012-03-13 03:45:59 UTC
Created attachment 58364 [details] [review]
Change default policies
Comment 11 Vincent Untz 2012-03-13 03:46:24 UTC
Created attachment 58365 [details] [review]
Do not use "all-edit" for jobs owned by someone else
Comment 12 Miloslav Trmac 2012-03-13 06:08:09 UTC
Please excuse my ignorance about the specifics,

(In reply to comment #9)
> org.opensuse.cupspkhelper.mechanism.devices-get: get a list of available
> devices. I see no reason to require authentication for this. Move to "yes".
Can this be used to read the printer configuration (in particular usernames and passwords of network printers)?

> org.opensuse.cupspkhelper.mechanism.printer-set-default: just change a default
> printer. This is not a harmful operation, as this can be reverted easily. Move
> to "yes".
OTOH it allows tricking users into printing private documents on a shared printer.  There already is a mechanism for per-user-defaults, so unprivileged users should not "need" this anyway unless they do want to affect other users.

> org.opensuse.cupspkhelper.mechanism.printer-local-edit,
> org.opensuse.cupspkhelper.mechanism.printer-remote-edit,
> org.opensuse.cupspkhelper.mechanism.class-edit: those can involve uploading a
> PPD file to CUPS, so we need to have some authentication to prevent this
> happening without the user being aware of the change. Move to "auth_self_keep".
Can this also be used to change the URI of a printer? (I'm thinking something like file:///etc/shadow in the worst case)
Comment 13 Vincent Untz 2012-03-13 06:45:22 UTC
(In reply to comment #12)
> Please excuse my ignorance about the specifics,

I'm not an expect in cups itself either, which is why I'm requesting comments before changing any of this :-)

> (In reply to comment #9)
> > org.opensuse.cupspkhelper.mechanism.devices-get: get a list of available
> > devices. I see no reason to require authentication for this. Move to "yes".
> Can this be used to read the printer configuration (in particular usernames and
> passwords of network printers)?

No, cups doesn't use the current printer configuration, but just tells us what devices the different backends can use to create a printer.

> > org.opensuse.cupspkhelper.mechanism.printer-set-default: just change a default
> > printer. This is not a harmful operation, as this can be reverted easily. Move
> > to "yes".
> OTOH it allows tricking users into printing private documents on a shared
> printer.  There already is a mechanism for per-user-defaults, so unprivileged
> users should not "need" this anyway unless they do want to affect other users.

Hrm. If we consider this argument, then the mere fact of allowing the edition/removal of a printer can lead to a similar situation. So that's really an argument where we require admin auth for anything related to printers :/

> > org.opensuse.cupspkhelper.mechanism.printer-local-edit,
> > org.opensuse.cupspkhelper.mechanism.printer-remote-edit,
> > org.opensuse.cupspkhelper.mechanism.class-edit: those can involve uploading a
> > PPD file to CUPS, so we need to have some authentication to prevent this
> > happening without the user being aware of the change. Move to "auth_self_keep".
> Can this also be used to change the URI of a printer? (I'm thinking something
> like file:///etc/shadow in the worst case)

Yes it can be used to change the URI of a printer. Note that cups, by default, doesn't allow file: URIs. If we do want to consider this case (which is arguably something we might want to do), then the only option would be to add a specific policy when the edition of a printer implies a file URI (and maybe URI with other schemes) -- or to only accept a white list of schemes.
Comment 14 Tim Waugh 2012-03-13 08:18:15 UTC
The changes proposed in comment #9 look correct to me.
Comment 15 Vincent Untz 2012-03-15 07:01:09 UTC
For reference, I filed https://bugzilla.novell.com/show_bug.cgi?id=752454 for openSUSE so that such changes get validated by the security team there.
Comment 16 Marek Kasik 2012-03-26 05:34:51 UTC
Hi,

sorry for late answer, I was on vacation and quite busy after that.

(In reply to comment #9)
> org.opensuse.cupspkhelper.mechanism.printer-local-edit,
> org.opensuse.cupspkhelper.mechanism.printer-remote-edit,
> org.opensuse.cupspkhelper.mechanism.class-edit: those can involve uploading a
> PPD file to CUPS, so we need to have some authentication to prevent this
> happening without the user being aware of the change. Move to "auth_self_keep".

This could lead to printing private documents to a printer other than we expect (if an user changes the URI). Such user could also change list of allowed/denied users for given printer.

The same apply for all-edit.

> org.opensuse.cupspkhelper.mechanism.all-edit: this one is harder, as it's
> actually a meta action, done the old way. Based on the way we use it, it could
> be moved to "auth_self_keep". However, we first need to change the code a bit
> so that it's not used for jobs not owned by the user.
Comment 17 Vincent Untz 2013-03-01 08:24:58 UTC
Marek is taking over maintainership, reassigning bugs to him.
Comment 18 Pacho Ramos 2013-08-29 12:49:10 UTC
Any updates on this?
Comment 19 Sriram Ramkrishna 2014-01-09 02:10:22 UTC
So, we had some G+ thread about this with a bunch of kernel folks again talking about this issue.  It would be nice to do something actionable here.