Description of problem: There's no point in having a LocalSocketGroup option in scan.conf to allow giving away the socket if the socket itself resides in an unreadable/unsearchable directory: [root@mail mail]# grep '^LocalSocketGroup' /etc/clamd.d/scan.conf LocalSocketGroup defang [root@mail mail]# ls -ld /var/run/clamd.scan drwx--x---. 2 clamscan clamscan 80 Jan 24 22:24 /var/run/clamd.scan [root@mail mail]# ls -l /var/run/clamd.scan/clamd.sock srw-rw----. 1 clamscan defang 0 Jan 24 22:24 /var/run/clamd.scan/clamd.sock [root@mail mail]# The permissions of /var/run/clamd.scan/ need to be 755 or 751. This problem was indicated when clamav-0.97.3-1601.fc16 was submitted for testing, but that was released despite this important flaw. I'm hoping that the maintainer will be more diligent in the future. Version-Release number of selected component (if applicable): clamav-0.97.3-1601.fc16 How reproducible: As above. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
not a bug; make the users which are allowed to use the clamav scanner service a member of the 'clamscan' group or use (suggested) a tcp socket and filter by '-m owner' iptable rules.
(In reply to comment #1) > not a bug; make the users which are allowed to use the clamav scanner service a > member of the 'clamscan' group or use (suggested) a tcp socket and filter by > '-m owner' iptable rules. Except that: (1) if you're running multiple Anti-Virus agents that are being used by the same clients (MTA's, MUA's, etc) they would *all* need to be in the clamscan group. (2) using a TCP socket wouldn't as easily allow for SElinux coverage rule inclusion for access to the AV service. (3) you'd need to patch clamav to remove the LocalSocketGroup directive if it isn't supported.
And let's be real here: we're talking about a trivial 1-line change: cat << EOF > $RPM_BUILD_ROOT%_sysconfdir/tmpfiles.d/clamd.scan.conf -d %scanstatedir 0710 %scanuser %scanuser +d %scanstatedir 0750 %scanuser %scanuser EOF
Errr, correct... actually: d %scanstatedir 0751 %scanuser %scanuser so that other groups can search the directory.
> (1) if you're running multiple Anti-Virus agents that are being used by the > same clients (MTA's, MUA's, etc) they would *all* need to be in the clamscan > group. clamd@scan is a service for users within the 'clamscan' group. > (2) using a TCP socket wouldn't as easily allow for SElinux coverage rule > inclusion for access to the AV service. I am not aware of a non-trivial system which works without local SELinux adaptations. So, one ore two rules more won't be a problem. > (3) you'd need to patch clamav to remove the LocalSocketGroup directive if it > isn't supported. ??? clamav-milter (which uses clamd@scan) works fine here without such a patch. > +d %scanstatedir 0750 %scanuser %scanuser will provide an insecure setup because socket is world writable
(In reply to comment #5) > > +d %scanstatedir 0750 %scanuser %scanuser > > will provide an insecure setup because socket is world writable Then fix the root cause! # Sets the permissions on the unix socket to the specified mode. # Default: disabled (socket is world accessible) -#LocalSocketMode 660 +LocalSocketMode 660 If the vulnerability is in the SOCKET's permissions then fix that. Not the directory that contains it.
sorry, won't happen. That's not the way how clamav-scanner is supposed to work.
(In reply to comment #7) > sorry, won't happen. That's not the way how clamav-scanner is supposed to work. It's the way clamav is supposed to work or it wouldn't have both the LocalSocketMode and LocalSocketGroup configuration options. What purpose does not handling these options correctly serve?
Created attachment 559717 [details] Fix socket and directory permissions This is a trivial fix to enforce the socket permissions on the socket itself and not on the directory. Can you please explain what the down side of this fix is?
What SELinux issues are you seeing?
I have been talking to Phillip about this problem in IRC. And I guess the fundemental problem here is you are program mimedefang running as the defang user, and it wants to tell clamscan (clamscan user) to scan files it owns. In all cases he has to add the clamscan user to the defang group if it is going to read files that are not world readable. Option 1 on clamscan would be to allow access to the world writable socket and change the permissions on the directory to 751 and the socket to 666. Option 2 would be to also add defang to the clamscan group and run the clamscan socket as 660 and the directory as 750 and owned by the clamscan group. Option 3 would be to run clamscan with the defang group and allow change the protection to 751 since the directory would still be owned by the clamscan group. I don't like option 3 since, if I had a third user that wanted access to clamscan I would have to add him to the defang group. Option 2 could be a problem if clamscan had a group writable directory or content available to the group that we did not want defang reading. Option 1 could be a problem if we were concerned about random users convincing clamscan to read content that we could cause it to be corrupted or if the clamscan socket code had bugs in it.
With Option 2, if the user changes the configuration line to: LocalSocketGroup xxx that group would still not be able to open the socket, as the socket would live in a directory that was o-rwx to other (i.e. to members of group 'xxx'). This violates the principle of least astonishment. I think that whatever option we go with, having the directory be 751 makes the most sense. Option 2 is a concern because if mimedefang were ever subverted, it could potentially write to any g+w files that clamscan owned (i.e. AV dictionaries, etc). Worth noting that the socket currently is created as mode 666 in Option 1. That's cause for concern.
clamav-scanner is a streaming only instance of 'clamd' and is more or less for demonstration purposes only. It has no special permissions (e.g. for reading MIMEDefang files) and the 'clamscan' user has minimal privileges (e.g. it has no (writable) home dir nor does it own files except the communication sockets). Sharing a clamd instance between multiple services (e.g. MIMEDefang and a web proxy) is risky, because e.g. the proxy service could initiate a scan of private defang files. Or, the defang service could DOS the proxy by 'echo nSHUTDOWN > /var/run/clamd.scan/scan.sock'. When you want a 'clamd' instance with more privileges, create such an instance. When you need only a streaming clamd scanner (which is not the case for defang) and do not want to add users to the 'clamscan' group, you can change ACLs of the socket dir. E.g. (untested) [Unit] After = tmpfiles.service Before = clamd Before = my-special.service [Service] Type = oneshot Exec = setfacl -m u:my-user:x /var/run/clamd.scan
(In reply to comment #13) > clamav-scanner is a streaming only instance of 'clamd' and is more or less for > demonstration purposes only. It has no special permissions (e.g. for reading > MIMEDefang files) and the 'clamscan' user has minimal privileges (e.g. it has > no (writable) home dir nor does it own files except the communication sockets). Any AV software to work with MIMEDefang has to be in the MIMEDefang group, or else MIMEDefang would have to run wide-open. There is nothing particular to clamav about that. > Sharing a clamd instance between multiple services (e.g. MIMEDefang and a web > proxy) is risky, because e.g. the proxy service could initiate a scan of > private defang files. Or, the defang service could DOS the proxy by 'echo > nSHUTDOWN > /var/run/clamd.scan/scan.sock'. So because sharing between multiple services is risky, you're going to stop clamav-scanner from running with MIMEDefang unshared? I don't get this logic. > When you want a 'clamd' instance with more privileges, create such an instance. > > When you need only a streaming clamd scanner (which is not the case for defang) > and do not want to add users to the 'clamscan' group, you can change ACLs of > the socket dir. E.g. (untested) I don't need to add users to the clamscan group: I only need to add the clamscan user to the defang group... if you set the permissions on /var/run/clamd.scan/ correctly. > [Unit] > After = tmpfiles.service > Before = clamd > Before = my-special.service > > [Service] > Type = oneshot > Exec = setfacl -m u:my-user:x /var/run/clamd.scan But you've still not answered my very simple question: Why exactly isn't having the directory /var/run/clamd.scan/ be 751 and the socket /var/run/clamd.scan/clamd.sock be 066 *not* the right thing to do? For that matter, why is having LocalSocketMode not work as it's supposed to *not* a regression?
That should be "0660" of course above... sigh.
This wasn't rhetorical: > But you've still not answered my very simple question: > > Why exactly isn't having the directory /var/run/clamd.scan/ be 751 and > the socket /var/run/clamd.scan/clamd.sock be 0660 *not* the right thing > to do? > > For that matter, why is having LocalSocketMode not work as it's supposed > to *not* a regression?
> Why exactly isn't having the directory /var/run/clamd.scan/ be 751 and > the socket /var/run/clamd.scan/clamd.sock be 066 *not* the right thing > to do? Changing directory mode to 0751 will render existing installations insecure. Patching clamd to set more restrictive default socket permissions will break existing installations which expect a world-writable file mode. clamd@scan is for members of the clamscan group; generally, clamd instances should not be shared between several servers. When you want clamav services for MIMEDefang, create an integration package which ships a dedicated clamd@defang instance. > For that matter, why is having LocalSocketMode not work as it's supposed > to *not* a regression? Although it might be possible to configure clamd@scan in the way described by you, this encourages an insecure setup by giving a shared clamd instance more permissions. I see only a very small gain in it and because of its effect on existing installations, I do not want to support it by the package.
(In reply to comment #17) > > Why exactly isn't having the directory /var/run/clamd.scan/ be 751 and > > the socket /var/run/clamd.scan/clamd.sock be 066 *not* the right thing > > to do? > > Changing directory mode to 0751 will render existing installations insecure. 'Insecure' how exactly? What's the vulnerability in detail please? > Patching clamd to set more restrictive default socket permissions will break > existing installations which expect a world-writable file mode. How can they open the socket much less write to it if they don't have access to the directory? This doesn't make any sense. And patching it how? There's no patching of the actual source required. Just changing the file directory attributes in the .rpm packaging itself. > clamd@scan is for members of the clamscan group; generally, clamd instances > should not be shared between several servers. When you want clamav services > for MIMEDefang, create an integration package which ships a dedicated > clamd@defang instance. It's not a question that it can't be shared between 'several servers'. It can't even be made to run with a single other service (mimedefang) in this case because of the overly restrictive permissions on the directory. > > For that matter, why is having LocalSocketMode not work as it's supposed > > to *not* a regression? > > Although it might be possible to configure clamd@scan in the way described by > you, this encourages an insecure setup by giving a shared clamd instance more > permissions. I see only a very small gain in it and because of its effect on > existing installations, I do not want to support it by the package. How about this? Why don't you actually *try* my patch and then tell me what specific problems/vulnerabilities it has? It's a 3-line patch. What 'more permissions' are you talking about? clamav-milter uses /var/run/clamav-milter/ for it's socket's directory, and clamav-scanner uses /var/run/clamd.scan/ for it's socket's directory. Changing the permissions on JUST the latter, /var/run/clamd.scan/ would not affect *any other instances* of clamav. This is what my patch does. This is what I've said repeatedly my patch does. And you'd know this if you had tried to apply it and test it before dismissing it. The various instances of clamav should *all* be compartmentalized by having different subdirectories in /var/run/ ...
(In reply to comment #9) > Created attachment 559717 [details] > Fix socket and directory permissions > > This is a trivial fix to enforce the socket permissions on the socket itself > and not on the directory. > > Can you please explain what the down side of this fix is? 2nd request: can I please get a code review of this patch to find out what specifically is wrong with it? It's 3 lines of changes.
> 'Insecure' how exactly? What's the vulnerability in detail please? # service clamd@scan restart Redirecting to /bin/systemctl restart clamd # pidof clamd 9662 # chmod 0751 /run/clamd.scan (emulating the requested change) # su nobody -s /bin/sh -c 'id; echo nSHUTDOWN | nc -U /run/clamd.scan/clamd.sock' uid=99(nobody) gid=99(nobody) Gruppen=99(nobody) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 # pidof clamd #
(In reply to comment #20) > > 'Insecure' how exactly? What's the vulnerability in detail please? > > # service clamd@scan restart > Redirecting to /bin/systemctl restart clamd > # pidof clamd > 9662 > > # chmod 0751 /run/clamd.scan (emulating the requested change) > > # su nobody -s /bin/sh -c 'id; echo nSHUTDOWN | nc -U > /run/clamd.scan/clamd.sock' > uid=99(nobody) gid=99(nobody) Gruppen=99(nobody) > Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > > # pidof clamd > # Which is exactly why my patch ALSO contains a line to uncomment the line: #LocalSocketMode 0660 so that the socket gets opened as 0660. Why are you going out of your way to avoid the specifics of my patch????
I even said in comments 14-16 that the socket should be configured as 0660 specifically to mitigate this exact problem.
> Which is exactly why my patch ALSO contains a line to uncomment the line: your patch changes the packed configuration file. I does not have any effect (except the creation of a clamd.d/scan.conf.rpmnew file) on existing installations (which have by default '#LocalSocketMode' meaning 0666) And before you ask: doing stupid things like patching scan.conf in %post or %trigger is a no-go because it is non-working (cfg might come from cfengine or so, might use some kind of include feature) and dangerous (as admin, I do not want silent configuration changes).
So on a new install, set the directory permissions (via tmpfiles.d) to be 751, and the socket 0660, and on an existing install warn the user...(In reply to comment #23) > > Which is exactly why my patch ALSO contains a line to uncomment the line: > > your patch changes the packed configuration file. I does not have any effect > (except the creation of a clamd.d/scan.conf.rpmnew file) on existing > installations (which have by default '#LocalSocketMode' meaning 0666) > > And before you ask: doing stupid things like patching scan.conf in %post or > %trigger is a no-go because it is non-working (cfg might come from cfengine or > so, might use some kind of include feature) and dangerous (as admin, I do not > want silent configuration changes). So on a new install, set the directory permissions (via tmpfiles.d) to be 751, and the socket 0660, and on an existing install warn the user... Anyway, whenever security vulnerabilities are found with file permissions, this problem has come up in the past--and it hasn't been an impediment to having future installs resolve the vulnerability.
As a side note, the /usr/share/doc/clamav-server-0.9.73/README is wrong. Or else the /usr/share/clamav/clamd-wrapper is. Either the README is skipping the step where you need to create: # echo "d /var/run/clamd.<SERVICE> 0710 <USER> clamscan" > /etc/tmpfiles.d/clamd.<SERVICE>.conf but after emulating these steps by hand (or else rebooting), you still need: # chcon -t clamd_var_run_t /var/run/clamd.<SERVICE> The other possibility is that the clamd-wrapper script is wrong and it needs to do: CLAMD_DIR=`dirname $CLAMD_PIDFILE` [ -d $CLAMD_DIR ] || { mkdir $CLAMD_DIR chmod 0710 $CLAMD_DIR XUSER=`awk '/^User / {print $2; } | tail -1'` : ${XUSER:=clamscan} chown $XUSER.clamscan $CLAMD_DIR chcon -t clamd_var_run_t $CLAMD_DIR } and hope that's correct... Also, the steps that describe creating /etc/init.d/clamd.<SERVICE> don't mention how to stop the init scripts from redirecting to systemctl and failing. I found I had to put: SYSTEMCTL_SKIP_REDIRECT=1 into /etc/init.d/clamd.<SERVICE> as the first executable line. There might be an easier way to do this, but I don't know it.
Also, the clamd.init script (once copied over and after the 'chkconfig'), you also need to run: % restorecon -R -v /etc/rc.d after the chkconfig or SElinux will block the client from connecting to the clamd socket.
Also, did the Fedora community do away with attaching patches as diffs so they could be discussed first before being committed? Because I find the new contents of README-clamd to be less than useful: clamd@<SERVICE>.service: (systemd instance) * instance of clamd@.service where does this file go? What's in it? What does it come from? Also, the latest README removes references to clamd.init and clamd.sysconfig, but clamd.SERVICE.init and clamd.sysconfig are still present in the source tree and in the clamav.spec file.
Looking at git a bit more, it seems that the file: /lib/systemd/system/clamd@.service will eventually by part of the package, and what will need to be done is: % ln -sf clamd@.service /lib/systemd/system/clamd@<SERVICE>.service % systemctl --system daemon-reload % systemctl enable clamd@<SERVICE>.service % systemctl start clamd@<SERVICE>.service to enable and start the service. Please update the README to include these steps.
Looking at the .spec file, I see: ! test -x /sbin/restorecon || /sbin/restorecon %freshclamlog for what it's worth, a lot of people use the shorthand: [ ! -x /sbin/restorecon ] || /sbin/restorecon %freshclamlog and find that a lot more readable, or better yet: [ -x /sbin/restorecon ] && /sbin/restorecon %freshclamlog which is more to the point since it makes it clear that the 2nd part is only to be done if the first part is true, as opposed to doing the 2nd part only when the first part fails.
Created attachment 566640 [details] Add clamav+mimedefang integration subpackage As comment #17 recommends.
as explained in #754276 I do not want to ship such integration packages within clamav itself (nor do I request that this is done by the exim, defang, amavisd, ... packages). A separate package written by somebody who knows both clamav and the other program is a more clean solution. Regarding you scriptlets: | [ -x /sbin/restorecon ] && /sbin/restorecon %freshclamlog is wrong because expression fails (and might abort the rpm %scriptlet) when /sbin/restorecon does not exist. Generally, there is not needed a 'clamd@<SERVICE>.service' file or link. It is sufficient to create 'After = clamd@<SERVICE>.service' and/or similar entries in the unitfile of the other program. But these are generic systemd setup steps which are explained more detailed by the systemd documentation. The SysV stuff (inclusive the clamd-wrapper) is going to die in the midterm (RHEL5 EOL is the target date) and will see only fixes for really critical bugs. Thanks for pointing to SYSTEMCTL_SKIP_REDIRECT=1; I will check what's going on there.
(In reply to comment #31) > as explained in #754276 I do not want to ship such integration packages within > clamav itself (nor do I request that this is done by the exim, defang, amavisd, > ... packages). > > A separate package written by somebody who knows both clamav and the other > program is a more clean solution. Except that not updating the integration package's file when the file it's derived from (i.e. what's packaged in clamav) would lead to it quickly getting out of date. If changes happen in clamav (say default settings change, the SElinux context changes, etc) then all that needs to be reflected in the integration package as well. They are too closely coupled to not be done as a subpackage one from the other. > Regarding you scriptlets: > > | [ -x /sbin/restorecon ] && /sbin/restorecon %freshclamlog > > is wrong because expression fails (and might abort the rpm %scriptlet) when > /sbin/restorecon does not exist. Ah, yes. To make sure the expression exits with truth, you'd need: [ ! -x /sbin/restorecon ] || /sbin/restorecon %freshclamlog > Generally, there is not needed a 'clamd@<SERVICE>.service' file or link. It is > sufficient to create 'After = clamd@<SERVICE>.service' and/or similar entries > in the unitfile of the other program. But these are generic systemd setup > steps which are explained more detailed by the systemd documentation. > > The SysV stuff (inclusive the clamd-wrapper) is going to die in the midterm > (RHEL5 EOL is the target date) and will see only fixes for really critical > bugs. > > Thanks for pointing to SYSTEMCTL_SKIP_REDIRECT=1; I will check what's going on > there. Did you also see the change in my patch to the system .service file to indicate the PIDFile?
I do not see a reason to use PIDFile with systemd; pidfiles are a hack from old SysV init days. Managing them causes lot of trouble and every modern init system works well without them.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I have to run clamfix.sh , every reboot on F16. cat clamfix.sh mkdir /var/run/clamd.clamd chown qscand:qscand /var/run/clamd.clamd
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
(In reply to comment #33) > I do not see a reason to use PIDFile with systemd; pidfiles are a hack from > old SysV init days. Managing them causes lot of trouble and every modern > init system works well without them. Correct. but you need add : [Install] WantedBy=multi-user.target to may enable it and start it on boot also seems need set to run before spamassassin .
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
10:19:40 : Heruntergeladen: (1/14): clamav-0.97.8-1.fc18.x86_64.rpm ( 922 k ) 10:19:46 : Heruntergeladen: (2/14): clamav-data-0.97.8-1.fc18.noarch.rpm ( 58 M ) 10:19:46 : Heruntergeladen: (3/14): clamav-devel-0.97.8-1.fc18.x86_64.rpm ( 30 k ) 10:19:46 : Heruntergeladen: (4/14): clamav-filesystem-0.97.8-1.fc18.noarch.rpm ( 17 k ) 10:19:46 : Heruntergeladen: (5/14): clamav-lib-0.97.8-1.fc18.x86_64.rpm ( 3.6 M ) 10:19:46 : Heruntergeladen: (6/14): clamav-milter-0.97.8-1.fc18.x86_64.rpm ( 85 k ) 10:19:46 : Heruntergeladen: (7/14): clamav-milter-systemd-0.97.8-1.fc18.noarch.rpm ( 17 k ) 10:19:46 : Heruntergeladen: (8/14): clamav-scanner-0.97.8-1.fc18.noarch.rpm ( 23 k ) 10:19:46 : Heruntergeladen: (9/14): clamav-scanner-systemd-0.97.8-1.fc18.noarch.rpm ( 17 k ) 10:19:46 : Heruntergeladen: (10/14): clamav-server-0.97.8-1.fc18.x86_64.rpm ( 92 k ) 10:19:47 : Heruntergeladen: (11/14): clamav-server-systemd-0.97.8-1.fc18.noarch.rpm ( 17 k ) 10:19:47 : Heruntergeladen: (12/14): clamav-update-0.97.8-1.fc18.x86_64.rpm ( 83 k ) 10:19:47 : Heruntergeladen: (13/14): clamsmtp-1.10-10.fc18.x86_64.rpm ( 44 k ) 10:19:47 : Heruntergeladen: (14/14): sendmail-milter-8.14.7-1.fc18.x86_64.rpm ( 69 k ) 10:19:47 : YUM: Running Transaction Check 10:19:47 : YUM: --> Fülle Verarbeitungsset mit ausgewählten Paketen. Bitte warten. 10:19:47 : YUM: ---> Paket clamav-lib.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav-scanner.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav-update.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav-server.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav-milter-systemd.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav-devel.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav-server-systemd.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav-milter.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav-data.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamav-filesystem.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket clamsmtp.x86_64 0:1.10-10.fc18 markiert, um an update zu werden 10:19:47 : YUM: ---> Paket sendmail-milter.x86_64 0:8.14.7-1.fc18 markiert, um an update zu werden I grab from yumex the error messages: 10:19:47 : YUM: ---> Paket clamav-scanner-systemd.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden 10:19:47 : RPM Scriptlet: Aufruf: groupadd [Optionen] GRUPPE 10:19:47 : YUM: Optionen: 10:19:47 : YUM: -f, --force Ohne Fehler beenden, falls die Gruppe 10:19:47 : YUM: bereits existiert 10:19:47 : YUM: und Operation für -g abbrechen, falls die 10:19:47 : YUM: GID bereits verwendet wird 10:19:47 : YUM: -g, --gid GID GID für die neue Gruppe benutzen 10:19:47 : YUM: -h, --help Diese Hilfe anzeigen, sonst nichts 10:19:47 : YUM: -K, --key SCHLÜSSEL=WERT Die Vorgabewerte in /etc/login.defs 10:19:47 : YUM: überschreiben 10:19:47 : YUM: -o, --non-unique Erstellen einer Gruppe mit nicht 10:19:47 : YUM: einmaliger (doppelter) GID erlauben 10:19:47 : YUM: -p, --password PASSWORT Dieses verschlüsselte PASSWORT für die 10:19:47 : YUM: neue Gruppe verwenden 10:19:47 : YUM: -r, --system Eine Systemgruppe erstellen 10:19:47 : YUM: -R, --root CHROOT_VERZ Verzeichnis für chroot 10:19:47 : YUM: useradd: Gruppe »clamupdate« existiert nicht. 10:19:47 : clamav-filesystem-0.97.8-1.fc18.noarch ist installiert 10:19:48 : RPM Scriptlet: warning: user clamupdate does not exist - using root 10:19:48 : YUM: warning: group clamupdate does not exist - using root 10:19:49 : clamav-data-0.97.8-1.fc18.noarch ist installiert 10:19:49 : RPM Scriptlet: warning: user clamupdate does not exist - using root 10:19:49 : YUM: warning: group clamupdate does not exist - using root 10:19:49 : YUM: warning: user clamupdate does not exist - using root 10:19:49 : YUM: warning: group clamupdate does not exist - using root 10:19:49 : clamav-lib-0.97.8-1.fc18.x86_64 ist installiert 10:19:50 : clamav-server-0.97.8-1.fc18.x86_64 ist installiert 10:19:50 : clamav-server-systemd-0.97.8-1.fc18.noarch ist installiert 10:19:50 : RPM Scriptlet: Aufruf: groupadd [Optionen] GRUPPE 10:19:50 : YUM: Optionen: 10:19:50 : YUM: -f, --force Ohne Fehler beenden, falls die Gruppe 10:19:50 : YUM: bereits existiert 10:19:50 : YUM: und Operation für -g abbrechen, falls die 10:19:50 : YUM: GID bereits verwendet wird 10:19:50 : YUM: -g, --gid GID GID für die neue Gruppe benutzen 10:19:50 : YUM: -h, --help Diese Hilfe anzeigen, sonst nichts 10:19:50 : YUM: -K, --key SCHLÜSSEL=WERT Die Vorgabewerte in /etc/login.defs 10:19:50 : YUM: überschreiben 10:19:50 : YUM: -o, --non-unique Erstellen einer Gruppe mit nicht 10:19:50 : YUM: einmaliger (doppelter) GID erlauben 10:19:50 : YUM: -p, --password PASSWORT Dieses verschlüsselte PASSWORT für die 10:19:50 : YUM: neue Gruppe verwenden 10:19:50 : YUM: -r, --system Eine Systemgruppe erstellen 10:19:50 : YUM: -R, --root CHROOT_VERZ Verzeichnis für chroot 10:19:50 : YUM: useradd: Gruppe »clamscan« existiert nicht. 10:19:51 : clamav-scanner-0.97.8-1.fc18.noarch ist installiert 10:19:52 : clamav-scanner-systemd-0.97.8-1.fc18.noarch ist installiert 10:19:52 : sendmail-milter-8.14.7-1.fc18.x86_64 ist installiert 10:19:53 : RPM Scriptlet: Aufruf: groupadd [Optionen] GRUPPE 10:19:53 : YUM: Optionen: 10:19:53 : YUM: -f, --force Ohne Fehler beenden, falls die Gruppe 10:19:53 : YUM: bereits existiert 10:19:53 : YUM: und Operation für -g abbrechen, falls die 10:19:53 : YUM: GID bereits verwendet wird 10:19:53 : YUM: -g, --gid GID GID für die neue Gruppe benutzen 10:19:53 : YUM: -h, --help Diese Hilfe anzeigen, sonst nichts 10:19:53 : YUM: -K, --key SCHLÜSSEL=WERT Die Vorgabewerte in /etc/login.defs 10:19:53 : YUM: überschreiben 10:19:53 : YUM: -o, --non-unique Erstellen einer Gruppe mit nicht 10:19:53 : YUM: einmaliger (doppelter) GID erlauben 10:19:53 : YUM: -p, --password PASSWORT Dieses verschlüsselte PASSWORT für die 10:19:53 : YUM: neue Gruppe verwenden 10:19:53 : YUM: -r, --system Eine Systemgruppe erstellen 10:19:53 : YUM: -R, --root CHROOT_VERZ Verzeichnis für chroot 10:19:53 : YUM: useradd: Gruppe »clamilt« existiert nicht. 10:19:53 : clamav-milter-0.97.8-1.fc18.x86_64 ist installiert 10:19:53 : RPM Scriptlet: chown: ungültige Gruppe: „root:clamilt“ 10:19:53 : clamav-milter-systemd-0.97.8-1.fc18.noarch ist installiert 10:19:54 : clamsmtp-1.10-10.fc18.x86_64 ist installiert 10:19:54 : clamav-update-0.97.8-1.fc18.x86_64 ist installiert 10:19:54 : RPM Scriptlet: /usr/bin/chown: ungültige Gruppe: „root:clamupdate“ 10:19:55 : clamav-0.97.8-1.fc18.x86_64 ist installiert 10:19:55 : clamav-devel-0.97.8-1.fc18.x86_64 ist installiert 10:19:58 : Transaktion wurde erfolgreich ausgeführt 10:20:03 : RPM-Datenbank wird geschlossen und Yum entsperrt 10:20:03 : Yum-Backendprozess wurde beendet
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I think this still need review ...
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
reopen as it isn't fixed
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
This happens on Centos7/RHEL7 with the following packages clamav-data-0.99.4-1.el7.noarch clamav-lib-0.99.4-1.el7.x86_64 clamav-server-systemd-0.99.4-1.el7.noarch clamav-scanner-systemd-0.99.4-1.el7.noarch clamav-filesystem-0.99.4-1.el7.noarch clamav-server-0.99.4-1.el7.x86_64 clamav-scanner-0.99.4-1.el7.noarch The problem seems to be that tmpfiles.d uses /usr/lib/tmpfiles.d/clamd.scan.conf which is part of clamav-scanner package to set directory permission. No matter what you set as part of /etc/clamav/scan.conf matters (LocalSocket 666) because the other user can not access the socket due to the directory permissions. I did in fact add the other user to clamscan group and i can actually get into this directory (g+x permission)as the user but the application(python app) still experiences the error, only changing directory to 0711 or using setfacl resolves the issue. Not sure why this hasn't been changed like Philip said, most of the other directories in this /var/run/ are 755 or similar allowing others to access it if they have permission on the socket. Seems like writing another systemd service to alter this directory is effectively the only *hack* that is sustainable.
OK I read this bug again (In reply to Philip Prindeville from comment #30) > Created attachment 566640 [details] > Add clamav+mimedefang integration subpackage > > As comment #17 recommends. Attachment #566640 [details] still valid ? to include in clamav package ? (In reply to Philip Prindeville from comment #3) > And let's be real here: we're talking about a trivial 1-line change: > cat << EOF > $RPM_BUILD_ROOT%_sysconfdir/tmpfiles.d/clamd.scan.conf -d %scanstatedir 0710 %scanuser %scanuser +d %scanstatedir 0751 %scanuser %scanuser EOF I am considering in apply it ... (In reply to Philip Prindeville from comment #25) > As a side note, the /usr/share/doc/clamav-server-0.9.73/README is wrong. > > Or else the /usr/share/clamav/clamd-wrapper is. > > Either the README is skipping the step where you need to create: > > # echo "d /var/run/clamd.<SERVICE> 0710 <USER> clamscan" > > /etc/tmpfiles.d/clamd.<SERVICE>.conf > > but after emulating these steps by hand (or else rebooting), you still need: > > # chcon -t clamd_var_run_t /var/run/clamd.<SERVICE> OK , I will check it and about the rest, sysv and clamd-wrapper is deprecated a long time ago. (In reply to Philip Prindeville from comment #32) > Did you also see the change in my patch to the system .service file to > indicate the PIDFile? clamd@.service [1] , now don't have PrivateTmp = true , Type is not simple it is fork and ExecStart = don't have --nofork=yes . And in /etc/clamd.d/scan.conf the default of pidfile is disabled, so I think we don't need add PIDFile = /var/run/clamd.%i/clamd.pid [1] [Unit] Description = clamd scanner (%i) daemon After = syslog.target nss-lookup.target network.target [Service] Type = forking ExecStart = /usr/sbin/clamd -c /etc/clamd.d/%i.conf Restart = on-failure
(In reply to Stuart James from comment #46) > I did in fact add > the other user to clamscan group and i can actually get into this directory > (g+x permission)as the user but the application(python app) still > experiences the error, only changing directory to 0711 or using setfacl > resolves the issue. So you suggest that dir of /var/run/clamd.scan be 750 , the be readable by user of the group ? > Not sure why this hasn't been changed like Philip said, most of the other > directories in this /var/run/ are 755 or similar allowing others to access > it if they have permission on the socket. With permission 751 anybody may kill clamd with [1], which seems to me a good security argument [1] echo nSHUTDOWN | nc -U /run/clamd.scan/clamd.sock
(In reply to Sergio Monteiro Basto from comment #47) > OK I read this bug again > > (In reply to Philip Prindeville from comment #30) > > Created attachment 566640 [details] > > Add clamav+mimedefang integration subpackage > > > > As comment #17 recommends. > > Attachment #566640 [details] still valid ? to include in clamav package ? No idea. After 6 years I've lost the thread. > (In reply to Philip Prindeville from comment #3) > > And let's be real here: we're talking about a trivial 1-line change: > > > cat << EOF > $RPM_BUILD_ROOT%_sysconfdir/tmpfiles.d/clamd.scan.conf > -d %scanstatedir 0710 %scanuser %scanuser > +d %scanstatedir 0751 %scanuser %scanuser > EOF > > I am considering in apply it ... Great. I'm not sure what works any more and I don't have time to debug it all over again. Maybe Sergio has more insight at this point.
(In reply to Philip Prindeville from comment #49) > (In reply to Sergio Monteiro Basto from comment #47) > > OK I read this bug again > > > > (In reply to Philip Prindeville from comment #30) > No idea. After 6 years I've lost the thread. Attachment #566640 [details] is about server-systemd-mimedefang still interesting in mimedefang sub-package ? > > (In reply to Philip Prindeville from comment #3) > > > And let's be real here: we're talking about a trivial 1-line change: > > > > > cat << EOF > $RPM_BUILD_ROOT%_sysconfdir/tmpfiles.d/clamd.scan.conf > > -d %scanstatedir 0710 %scanuser %scanuser > > +d %scanstatedir 0751 %scanuser %scanuser > > EOF > > > > I am considering in apply it ... > > Great. I'm not sure what works any more and I don't have time to debug it > all over again. > > Maybe Sergio has more insight at this point. Maybe I will ask upstream (permissions of socket vs permissions of directory ). After thinking doesn't seemed to me wise modify this permissions . The point here is all the rest is fixed, just left these 3 details (these 2 more one line in documentation). Thanks.
*** Bug 1284253 has been marked as a duplicate of this bug. ***
clamav-0.100.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-331381dee5
clamav-0.100.1-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8b6214e6ae
clamav-0.100.1-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ecad18a061
clamav-0.100.1-3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-8b6214e6ae
clamav-0.100.1-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ecad18a061
clamav-0.100.1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-331381dee5
clamav-0.100.1-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-61b6e4545f
clamav-0.100.1-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c1c78a6e35
clamav-0.100.1-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c1c78a6e35
clamav-0.100.1-4.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-61b6e4545f
clamav-0.100.1-4.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
clamav-0.100.1-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
clamav-0.100.1-3.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
Problem still persistent in Fedora 29.
(In reply to Woti from comment #65) > Problem still persistent in Fedora 29. ll /var/run/clamd.scan/ -d drwx--x--- 2 clamscan virusgroup 40 abr 8 21:36 /var/run/clamd.scan/ is correct, what is your problem ?
It's wrong. Permissions should be 755 not 710. As it is descripet her https://bugzilla.redhat.com/show_bug.cgi?id=1284253. We get a lot of permission errors in Nextcloud if we want to use clamav as descripet her: https://docs.nextcloud.com/server/15/admin_manual/configuration_server/antivirus_configuration.html Changing manually from 710 to 755 is working. I'm running Fedora 29 Server-Edition with Nextcloud and ClamAv installed. If I do need to restart the server once in a while, every time I have to change the permissions to get ClamAV working properly.
Thanks for the report . Changing from 710 to 755 is a big security hole , as describe in these reports . I think you need add the user that needs to access to clamav socket to virusgroup and you will have permissions of the group . If I have time I will check nextcloud running with clamav . Feel free to reply . Thanks.
I did some testing. I added the user "apache" to the group "virusgroup" and the following error messages disappeared: [files_antivirus] Fatal: OCA\Files_Antivirus\BackgroundJob\BackgroundScanner::run, exception: Cannot connect to "/var/run/clamd.scan/clamd.sock": Permission denied (code 13) {"reqId":"h9b0q8yuvhYLncMjvdtQ","level":4,"time":"2019-04-16T10:45:44+02:00","remoteAddr":"","user":"--","app":"files_antivirus","method":"","url":"--","message":"OCA\\Files_Antivirus\\BackgroundJob\\BackgroundScanner::run, exception: Cannot connect to \"/var/run/clamd.scan/clamd.sock\": Permission denied (code 13)","userAgent":"--","version":"15.0.7.0","id":"5cb5970ae7f69"} [PHP] Error: stream_socket_client(): unable to connect to unix:///var/run/clamd.scan/clamd.sock (Permission denied) at /var/www/html/nextcloud/apps/files_antivirus/lib/Scanner/External.php#41 {"reqId":"h9b0q8yuvhYLncMjvdtQ","level":3,"time":"2019-04-16T10:45:44+02:00","remoteAddr":"","user":"--","app":"PHP","method":"","url":"--","message":"stream_socket_client(): unable to connect to unix:///var/run/clamd.scan/clamd.sock (Permission denied) at /var/www/html/nextcloud/apps/files_antivirus/lib/Scanner/External.php#41","userAgent":"--","version":"15.0.7.0","id":"5cb5970ae7f8d"} It looks like it works. I'll will do some more testing just to be sure and give you a reply.
I dont think that alone makes it a security issue the socket still needs permission right? For example in scan.conf ``` LocalSocketMode 660 ``` If you run that as regular user after giving /var/run/clamd.scan necessary O+X it won't do anything as you still dont have access to socket itself unless you choose to enable it ``` echo nSHUTDOWN | nc -U /var/run/clamd.scan/clamd.sock ``` Only if you set the LocalSocketMode to 666 then sure it will but that is choice of user to do that like any other setting on the server (such as setenforce 0) The problem is that the Localsocketmode is useless for Other as access to directory is not allowed by some other configuration that is really not doing anything but preventing O+X. Pretty much all other directories in /run are 755 so not really sure why this one needs not to be. If a user decides to turn off Selinux or to allow Other access to socket then it should be possible, it assumes you are running this on some sorta shared multi-user environment which is probably not the case. As per my above problem i have user in another primary group running an Python application, adding that user to clamscan group did not fix the problem, maybe if it was added to clamscan group as primary group it would work but that is not an option. In the end we moved the socket to a location we can control the access of the director without hacking a SystemD config as per the above comments. ideally the localsockemode is what defines if an Other user has access not the temporary directory where socket is created.
TLDR have file permissions with 755 and socket wiht 660 is the same 750 with socket 666 .
The directory is wrong permission when created, the localsocketmode should control who should be able to access the socket. This was in comment 9 in 2012 by Phil and still remains the same. The default should be 660 on the socket (as it is) but a user should be able to modify it and not have to worry about some useless directory permission that is only interfering with the configuration of the actual application.
cat /usr/lib/tmpfiles.d/clamd.scan.conf d /run/clamd.scan 0710 clamscan virusgroup is the correct, I already argued many times, epel 7 is now with this configuration and everyone is happy . what we may do is update nextcloud documentation [1] yum/dnf install clamav-update clamav add user apache to virusgroup etc etc [1] https://github.com/nextcloud/documentation/edit/master/admin_manual/configuration_server/antivirus_configuration.rst
I can confirm that it is working with Apache, if added to the group "virusgroup". No need to change the folder permission of /var/run/clamd.scan/ from 710 to 755. There are no more error messages apearing in the Nextcloud log file. This should have been updated in the Nextcloud documentation long ago. id apache uid=48(apache) gid=48(apache) Gruppen=48(apache),976(virusgroup) cat /usr/lib/tmpfiles.d/clamd.scan.conf d /run/clamd.scan 0710 clamscan virusgroup