Bug#645122: wrong permissions for /var/run/c-icap/c-icap.ctl named pipe

[Stephane Chazelas]

Package: c-icap
Version: 1:0.1.6-1
Severity: normal

Hiya,

The named pipe used to send control requests to the c-icap
server has incorrect permissions. That could even be considered
as a security issue as any user on the system can cause some of
the requests to c-icap to not be delivered to it or be
misinterpreted (by reading that file).

$ ll /var/run/c-icap/c-icap.ctl
prwxr--r-- 1 c-icap nogroup 0 Oct 12 19:20 /var/run/c-icap/c-icap.ctl|

Anybody can read from that fifo. Also, the gid is "nogroup".
That group shouldn't have any right. See the execution bit for
the user which doesn't make sense here either.

Also, /usr/share/doc/libc-icap-mod-clamav/README.Debian
instructs how to configure freshclam so that c-icap reloads the
virus db when it gets updated, but because freshclam is running
as "clamav", those instructions don't work because clamav
doesn't have right access to that named pipe.

IMO, the permissions should be:

prw--w---- c-icap c-icap

The c-icap group should be added and c-icap should run as
c-icap:c-icap, the clamav user shoud be made member of that group.

As it happens, the permissions of the named pipe are hardcoded
in the the c-icap source code. It would be nice to have a
configuration parameter to specify that mode, or be able to use
umask to set it.

Also, it seems c-icap puts itself in background *before*
creating that pipe, which makes it difficult to fix the
permissions reliably in c-icap init.d startup script.

-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages c-icap depends on:
ii adduser 3.113
ii libc6 2.13-21
ii libdb5.1 5.1.25-11
ii libicapapi0 1:0.1.6-1
ii lsb-base 3.2-28

c-icap recommends no packages.

Versions of packages c-icap suggests:
pn libc-icap-mod-clamav 1:0.1.6-1
pn libc-icap-mod-urlcheck <none>
pn squid3 <none>

-- Configuration Files:
/etc/c-icap/c-icap.conf changed:
PidFile /var/run/c-icap/c-icap.pid
CommandsSocket /var/run/c-icap/c-icap.ctl
Timeout 300
MaxKeepAliveRequests 100
KeepAliveTimeout 600
StartServers 3
MaxServers 10
MinSpareThreads 10
MaxSpareThreads 20
ThreadsPerChild 10
MaxRequestsPerChild 0
Port 1344
User c-icap
Group nogroup
ServerAdmin y...@your.address
ServerName YourServerName
TmpDir /tmp
MaxMemObject 131072
DebugLevel 1
ModulesDir /usr/lib/c_icap
ServicesDir /usr/lib/c_icap
TemplateDir /usr/share/c_icap/templates/
TemplateDefaultLanguage en
LoadMagicFile /etc/c-icap/c-icap.magic
RemoteProxyUsers off
RemoteProxyUserHeader X-Authenticated-User
RemoteProxyUserHeaderEncoded on
ServerLog /var/log/c-icap/server.log
AccessLog /var/log/c-icap/access.log
Service echo srv_echo.so
Include srv_clamav.conf

/etc/default/c-icap changed:
START=yes
DAEMON_OPTS=""


-- no debconf information



--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Tim Weippert]

Hi Stephane,

thanks for your investigation on this issue, my comments below.

On Wed, Oct 12, 2011 at 08:17:53PM +0100, Stephane Chazelas wrote:
> Package: c-icap
> Version: 1:0.1.6-1
> Severity: normal
>
> Hiya,
>
> The named pipe used to send control requests to the c-icap
> server has incorrect permissions. That could even be considered
> as a security issue as any user on the system can cause some of
> the requests to c-icap to not be delivered to it or be
> misinterpreted (by reading that file).
>
> $ ll /var/run/c-icap/c-icap.ctl
> prwxr--r-- 1 c-icap nogroup 0 Oct 12 19:20 /var/run/c-icap/c-icap.ctl|
>
> Anybody can read from that fifo. Also, the gid is "nogroup".
> That group shouldn't have any right. See the execution bit for
> the user which doesn't make sense here either.

Your right, the permission isn't optimal. The GID ist choosen from the config
file and therefore can be changed. I will update the package soon to 0.1.7 and
will implement an c-icap group and switch default config to use this group.

> Also, /usr/share/doc/libc-icap-mod-clamav/README.Debian
> instructs how to configure freshclam so that c-icap reloads the
> virus db when it gets updated, but because freshclam is running
> as "clamav", those instructions don't work because clamav
> doesn't have right access to that named pipe.
>
> IMO, the permissions should be:
>
> prw--w---- c-icap c-icap
>
> The c-icap group should be added and c-icap should run as
> c-icap:c-icap, the clamav user shoud be made member of that group.

Will look into this, if we do it via install scripts or just inform user about
the steps. Maybe someone don't want this integration or maybe someone runs
clamav on some other userid.

> As it happens, the permissions of the named pipe are hardcoded
> in the the c-icap source code. It would be nice to have a
> configuration parameter to specify that mode, or be able to use
> umask to set it.

You can use umask to change the permissions, as the source code uses
mkfifo which can be tweak by umask settings within the init script (umask
option for start-stop-daemon). Problem i think is that you can not set the
initial mode for the file, so umask fiddling is just hard.

> Also, it seems c-icap puts itself in background *before*
> creating that pipe, which makes it difficult to fix the
> permissions reliably in c-icap init.d startup script.

Yes, but if we use proper named pipe creation within the Package installation
scripts, we can create the named pipe, the daemon will not mess with the named
pipe if it already exists.

But will look for an patch for hardcoded mode settings and discuss this with
upstream.

cheers,
tim

--
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8