Wonderful this is indeed broken in cauldron, I guess it wasn't a bad idea to move packages I maintain (sendmail) 100% to systemd.

CC: (none) => cjw
Assignee: cooker => cjw

Nope I used a very old privoxy, guess I should now fix issues I had in the new version.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

So we don't need an ExecReload or a NM config?

Oops the current package does have this problem.


I tried to add ExecReload but privoxy still uses the old config file. So logrotate will have to restart the daemon instead.

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

I don't know anything about NetworkManager, don't use it so can't test anything related to this. How would something NM-related be a security issue? The issue with logrotate is that privoxy logs are not rotated, possibly filling the disk.

Proposed procedure:

1. install privoxy
2. start it (apparently not done on package install):
   systemctl start privoxy.service
3. set your favorite browser to use this proxy
   host: localhost  port: 8118
   Some browsers can be configured with an env var when started from the command line:  export http_proxy=localhost:8118
4. browse to a non-existent host, e.g. http://www.n.zz/

You should see a privoxy page saying "No such domain".

5. browse to one or two web sites to check that the proxy works properly


The logrotate function is not very easily tested. Here's what I did:

cd /var/log/privoxy
cat ../dracut.log >>logfile
# repeat above command until logfile is easily 1MB large
/sbin/logrotate /etc/logrotate.conf
# logrotate should not complain
# the dir should now contain an empty "logfile" and the large "logfile.1"
fuser /var/log/privoxy/*

The output of the fuser command should be
  logfile: <n>
and NOT
  logfile.1: <n> .

# remove (mostly) bogus logfile
rm -f logfile.1


After testing, change back the browser settings (and remove the privoxy package).

Updated packages are available for testing:

MGA3
Source RPM:
privoxy-3.0.21-1.1.mga3.src.rpm

Binary RPMS:
privoxy-3.0.21-1.1.mga3.i586.rpm
privoxy-3.0.21-1.1.mga3.x86_64.rpm


MGA4
Source RPM:
privoxy-3.0.21-2.1.mga4.src.rpm

Binary RPMS:
privoxy-3.0.21-2.1.mga4.i586.rpm
privoxy-3.0.21-2.1.mga4.x86_64.rpm


Proposed advisory:


Updated privoxy packages fix a security issue:

The logrotate configuration of the privoxy package did not function properly, causing its log files not to be rotated. The log file(s) could potentially fill up the disk.

Status: REOPENED => ASSIGNED
Assignee: cjw => qa-bugs

Looking it their Bugzilla, it looks like they've since discovered that reload indeed doesn't work and restart is needed (not fixed yet).  The NetworkManager thing appears to be just a bugfix not a security fix, but it looks like privoxy doesn't continue to work after a network interface config change and needs to be restarted.

Thanks Christiaan!

Advisory:
========================

Updated privoxy package fixes security vulnerability:

The logrotate configuration of the privoxy package did not function properly,
causing its log files not to be rotated. The log file(s) could potentially
fill up the disk.

References:
http://lists.opensuse.org/opensuse-updates/2014-07/msg00024.html

Here is how to configure it to testing.
http://evilshit.wordpress.com/2013/12/18/how-to-install-privoxy-and-combine-it-with-tor/

CC: (none) => ozkyster

Testing on Mageia 4-64, real H/w

Based on comment 6 and comment 10, my procedure was :


With current package :
--------------------

installed :
- privoxy-3.0.21-2.mga4.x86_64

- tor-0.2.4.23-1.mga4.x86_64
- lib64tsocks1-1.8-0.beta5.13.mga4.x86_64
- tsocks-1.8-0.benta5.13.mga4.x86_64


# cd /etc/tor/
# cp torrc.sample torrc
# nano /etc/torrc
and uncommented 
SocksPort 9050 # Default: Bind to localhost:9050 for local connections.
as user :
$ tor
and after a while :
Oct 28 17:25:51.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Oct 28 17:25:51.000 [notice] Bootstrapped 100%: Done.
and left it running

# nano /etc/privoxy/config
uncommented :
forward-socks5   /               127.0.0.1:9050 .
forward         192.168.*.*/     .
forward            10.*.*.*/     .
forward           127.*.*.*/     .

in firefox settings (advanced, network, settings)
Proxy HTTP : localhost
Port : 8118
and deleted "No proxy for : localhost"

Restarted firefox, went to a dummy address and had a message from privoxy : 
503 	
This is Privoxy 3.0.21 on localhost (127.0.0.1), port 8118, enabled
Forwarding failure

Went to http://whatismyipaddress.com/
which verified I had an anonymous tor IP address.

Stopped tor and privoxy services.
Installed updated-testing package privoxy-3.0.21-2.1.mga4

To be on the safe side, rebooted.
Tor and privoxy were running
In webbrowser, went to dummy address, to mageia site and to http://whatismyipaddress.com/
which confirmed I was using a tor address (Tor exit node located in Gulf of Guinea)

Tested the logrotate function as advised in comment 6
# cd /var/log/privoxy/
# cat ../shorewall-init.log >>logfile
when logfile was 1.1 Mb
# /sbin/logrotate /etc/logrotate.conf
As expected, /var/log/privoxy contained empty logfile and logfile.1 (1.1Mb)
# fuser /var/log/privoxy/* gave logfile: 11042 (and didn't mention logfile.1)

Worked well then

CC: (none) => olchal
Whiteboard: MGA3TOO => MGA3TOO MGA4-64-OK

Tested successfully Mageia 3 i586 and Mageia 4 i586 with the procedure in Comment 6.

Just curious, what purpose does the /var/log/privoxy/logfile serve?  It doesn't log anything when you browse through the proxy.

Whiteboard: MGA3TOO MGA4-64-OK has_procedure => MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK has_procedure

Here it logs every access because I have  "debug 1025" in the config file. The default value for the debug setting is 0 which (according to documentation) only logs errors fatal for the daemon.

Testing privoxy on Mageia3-64 HW, same procedure

Current package :
---------------
- privoxy-3.0.21-1.mga3.x86_64

with tor
- tor-0.2.4.23-1.mga3.x86_64
- tsocks-1.8-0.beta5.12.mga3.x86_64
- lib64tsocks1-1.8-0.beta5.12.mga3.x86_64

In /etc/privoxy/config,

I also uncommented to have more input in privoxy logfile (as I was curious after reading comment 12 from David):

  debug     1 # Log the destination for each request Privoxy let through. See also debug 1024.
  debug     2 # show each connection status
  
Tests ok, I could also verify that logfile was growing quite fast (more than 1 mb after visiting 6 sites)

  Updated to :
  ----------
  
- privoxy-3.0.21-1.1.mga3.x86_64

Tests ok, logrotate functionning as expected, could stop and restart privoxy service.

Whiteboard: MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK has_procedure => MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK MGA3-64-OK has_procedure

Thanks Olivier.

Validating now.

Could someone please upload the advisory?

Sysadmins, once the advisory is uploaded, please push to core/updates_testing.  Thanks.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Advisory uploaded.

CC: (none) => remi
Whiteboard: MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK MGA3-64-OK has_procedure => MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK MGA3-64-OK has_procedure advisory

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2014-0463.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

LWN reference for the logrotate issue:
http://lwn.net/Vulnerabilities/622611/