Bug 849932 - privoxy is only executable for the user privoxy.
privoxy is only executable for the user privoxy.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: privoxy (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Gwyn Ciesla
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-21 05:25 EDT by Till Maas
Modified: 2012-12-20 10:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 10:00:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Till Maas 2012-08-21 05:25:08 EDT
Description of problem:
privoxy is only executable for the user privoxy.

Version-Release number of selected component (if applicable):
privoxy-3.0.16-6.fc17

How reproducible:
always

Steps to Reproduce:
1. privoxy --help
  
Actual results:
the shell complains, that /usr/sbin/privoxy is not executable

Expected results:
privoxy should show its help.

Additional info:
ls -la /usr/sbin/privoxy shows, that it is owned by privoxy:privoxy with permissions rwxr--r-- instead of rxwr-xr-x, but it is also unlear why it is owned by the user privoxy. This might be a bug as well.
Comment 1 Till Maas 2012-10-01 07:28:35 EDT
ping
Comment 2 Gwyn Ciesla 2012-10-01 07:53:57 EDT
Missed this somehow, will look into it today.
Comment 3 Gwyn Ciesla 2012-10-01 08:14:48 EDT
I've got an update to 3.0.19 ready, and I've looked over the spec and the upstream docs, and all I can see is references to running it a) as a service and b) as a non-root user.  Can you outline the use case for running it as an arbitrary unprivileged user from the shell?  There may be one I've not thought of.  Multiple instances, maybe, but that could be implemented with multiple customized systemd unit files.
Comment 4 Till Maas 2012-10-01 08:42:03 EDT
(In reply to comment #3)
> I've got an update to 3.0.19 ready, and I've looked over the spec and the
> upstream docs, and all I can see is references to running it a) as a service
> and b) as a non-root user.  Can you outline the use case for running it as
> an arbitrary unprivileged user from the shell?  There may be one I've not
> thought of.  Multiple instances, maybe, but that could be implemented with
> multiple customized systemd unit files.

I sometimes start it by hand with a local config file to "convert" an SSH created socks proxy to an http proxy.
Comment 5 Gwyn Ciesla 2012-10-01 08:44:45 EDT
Sounds useful.  I'll keep it owned by the privoxy user, but I'll go from 744 to 755.
Comment 6 Fedora Update System 2012-10-01 09:05:16 EDT
privoxy-3.0.19-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/privoxy-3.0.19-1.fc18
Comment 7 Fedora Update System 2012-10-01 09:05:27 EDT
privoxy-3.0.16-6.1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/privoxy-3.0.16-6.1.fc17
Comment 8 Till Maas 2012-10-01 09:26:51 EDT
(In reply to comment #5)
> Sounds useful.  I'll keep it owned by the privoxy user, but I'll go from 744
> to 755.

Thank you. But why do you want to keep in owned by privoxy instead of root? Afaics this only weakens security as this allows the privoxy service if it is compromised to modify a binary that might be in the path of other users and be used by them.
Comment 9 Gwyn Ciesla 2012-10-01 09:33:24 EDT
If the service is compromised, it will be contained to the privoxy user.  If it runs as root, it gets the whole system.
Comment 10 Till Maas 2012-10-01 09:42:30 EDT
(In reply to comment #9)
> If the service is compromised, it will be contained to the privoxy user.  If
> it runs as root, it gets the whole system.

The service can still run as privoxy without the binary being owned by the privoxy user. The user privoxy is run as seems to be configured in the init script.
Comment 11 Gwyn Ciesla 2012-10-01 09:49:21 EDT
Ah, I see what you mean, in part.  It might be unnecessary, but I still don't see how that ownership is actively harmful.
Comment 12 Till Maas 2012-10-01 09:55:24 EDT
(In reply to comment #11)
> Ah, I see what you mean, in part.  It might be unnecessary, but I still
> don't see how that ownership is actively harmful.

If the service is compromised when it is running as privoxy, /usr/sbin/privoxy (and /etc/privoxy/ as I just saw) can be modified, which for example allows to manifest the infection for the future. Also if a different user runs /usr/sbin/privoxy after malicious modification, the user's account is also compromised.

Regarding /etc/privoxy being writeable by the privoxy user: When the service is compromised, this allows to persistently modify the configuration of privoxy. Here it would also be better to have the files owned by root and only readable by privoxy.
Comment 13 Gwyn Ciesla 2012-10-01 10:01:09 EDT
Gotcha, that makes perfect sense.  I'll correct that.
Comment 14 Fedora Update System 2012-10-01 16:03:22 EDT
Package privoxy-3.0.19-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing privoxy-3.0.19-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15150/privoxy-3.0.19-2.fc18
then log in and leave karma (feedback).
Comment 15 Fedora Update System 2012-12-20 10:00:03 EST
privoxy-3.0.16-6.2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.