Ticket #277 (closed task: fixed)

Opened 4 years ago

Last modified 4 years ago

what to do about the default user-can-install-pkgs policy kit setting for package kit

Reported by: skvidal Owned by:
Priority: major Keywords: meeting
Cc: till Blocked By:
Blocking:

Description

Proposal topic

I think we need to discuss whether or not to push an update which changes this: https://bugzilla.redhat.com/show_bug.cgi?id=534047

Change History

comment:1 follow-up: ↓ 3 Changed 4 years ago by dwmw2

Hell yes. Aside from the DoS it permits by filling the disk, it also massively increases security exposure. No longer can you allow users to have accounts on the box on the basis that you've uninstalled everything non-essential and you have confidence in the installed package set; you're now vulnerable to every local exploit in every package in every configured repository, as I understand it.

I might even add third-party repositories so that I can install one or two packages (like my printer driver) which aren't available in Fedora for various reasons -- and this would allow users to bring in any package from those repositories too, wouldn't it?

It was a stunningly bad idea to allow this in the first place.

comment:2 follow-up: ↓ 4 Changed 4 years ago by kkofler

My position: this is a bad idea indeed, and we should issue a security update which changes the policy to the same as in Fedora 11 (require root authorization once per user, allow keeping it indefinitely), that should strike the proper balance between convenience and security (it has always worked fine).

comment:3 in reply to: ↑ 1 ; follow-up: ↓ 7 Changed 4 years ago by rhughes

Replying to dwmw2:

you're now vulnerable to every local exploit in every package in every configured repository, as I understand it.

How's this different from inserting a USB pendrive and running a program from that?

It was a stunningly bad idea to allow this in the first place.

In your opinion. In a "desktop" distribution it lets us fulfil some pretty important use cases like installing clipart and codecs.

comment:4 in reply to: ↑ 2 Changed 4 years ago by rhughes

Replying to kkofler:

require root authorization once per user, allow keeping it indefinitely

That option is available in PolicyKit? anymore, so it's not really an option.

comment:5 Changed 4 years ago by kkofler

Then PolicyKit? 1 needs to be fixed urgently. It should have been obvious right from the start that supporting this is an essential requirement for it to be suitable as a replacement for the old PolicyKit?. It's pretty sad that the new PolicyKit? got rushed in without regards to regressions (see also the lack of a policy editor, which makes such bad defaults all the more scary).

comment:6 Changed 4 years ago by kkofler

Actually, I think this PolicyKit 1 limitation can be worked around inside PackageKit: https://bugzilla.redhat.com/show_bug.cgi?id=534047#c141

comment:7 in reply to: ↑ 3 ; follow-up: ↓ 8 Changed 4 years ago by djao

Replying to rhughes:

How's this different from inserting a USB pendrive and running a program from that?

You can't run programs from USB drives. The default mount options for automounted volumes include noexec. In fact, this is *why* the default mount options include noexec. Even if you try to destroy your system by (say) copying the program over to your home directory and setting it executable, modes such as setuid root won't be preserved. By contrast, when a package is installed, you *do* get the setuid root bits.

It's a really basic fact that executable files from system installed packages can do much more damage than executable files from external volumes. In fact, it concerns me that you don't realize the difference, since you're supposed to have thought of such things prior to making this decision. The clear implication is that this change was poorly thought out to begin with.

comment:8 in reply to: ↑ 7 Changed 4 years ago by till

Replying to djao:

Replying to rhughes:

How's this different from inserting a USB pendrive and running a program from that?

You can't run programs from USB drives. The default mount options for automounted volumes include noexec. In fact, this is *why* the default mount options include noexec.

The options also include nodev and nosuid, which are imho much more important, because they remove any special privileges from the files. Which is something the policiy kit installation does not. A feature in package kit to allow users to install packages e.g. in their home directory, which then thanks to some overlay magic that needs to be written, allows them to use the programs for tasks that do not need extra privileges, would be something that could be allowed by default imho.

comment:9 Changed 4 years ago by till

  • Cc till added

comment:10 Changed 4 years ago by riggs

The most disturbing aspect of this change is it was not openly discussed beforehand. The vast majority of commenters on the bugzilla ticket agree that this is an extremely significant change in security policy. However, the developers who made this change either did not agree with this assessment, or did not care to discuss the matter openly with the larger community. In fact, they didn't even feel it necessary to mention this change in the release notes, much less make inform users of the required actions to reverse this change, until there was a public outcry. And unfortunately, at the time of this writing, the instructions in the release notes are incorrect.

What further disturbs me is the developer's dismissive, defensive and even hostile responses when questioned about these changes by others. However, I do realize this is something beyond the control of this committee.

All that said, I also believe that allowing non-privileged users to install software by default is very unwise, especially when the steps required to prevent this are anything but obvious.

comment:11 Changed 4 years ago by notting

  • Status changed from new to closed
  • Resolution set to fixed

This ticket is closed - an update was pushed.

Note: See TracTickets for help on using tickets.