Bug 1426863
| Summary: | unmaintained? package ufdbguard instead? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Brian J. Murrell <brian> |
| Component: | squidGuard | Assignee: | Gwyn Ciesla <gwync> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | epel7 | CC: | gwync |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-07-23 01:06:13 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Brian J. Murrell
2017-02-25 22:19:41 UTC
Is this package SOOOOO un-maintained that even bug reports about it are not being dealt with? I wouldn't say TOTALLY un-maintained but I would say that the maintainer has had a lot on her plate lately. That said: While I'm normally a proponent of keeping programs alive even if more or less dead upstream as long as they're useful, squidGuard is network facing and this poses a risk. I'm not familiar with ufdbguard per-se, but it does look like a viable replacement. However, I no longer personally use squidGuard, or even squid, so testing ufdbguard would be slightly more challenging than usual. I would be willing to package it if there's a need, and someone willing to help test. If you're willing to test, let's do this thing. Totally willing to test. FWIW, ufdbguard does already supply an RPM package, but they don't follow the (Red Hat) FHS and they don't supply a systemd unit file so it might not be a huge amount of work. It might be useful though to "upgrade" existing ufdbguard installations to the proper FHS by moving the various files around in the %post. Ok, I'll get on it, and I'll post links to packages when there's something to test. What release and arch do you need? I'll look at their spec and certainly refer to it but I'll probably start from scratch. I'm using CentOS 7 on x86_64. Cool. I'll make it work for that as well. Is the 6755 perm on /usr/sbin/ufdbsignal necessary? Also, how important is it to support the /etc/sysconfig file? It's possible with systemd but it's a pain. I don't actually use ufdbsignal. Just given the name, I suspect it's a helper that allows a non-root process to modify the filtering database and then signal ufdbguard to re-read it. I don't think I modify anything in /etc/sysconfig/ufdbguard, but I could see a case for somebody wanting to modify things like DOWNLOAD_USER, DOWNLOAD_PASSWORD, ADMIN_EMAIL, BLACKLIST_DIR. That said, other than the export ... statements, that file should be usable with EnvironmentFile=-/etc/sysconfig/ufdbguard shouldn't it? Will systemd simply ignore the export statements? I don't recall. I'm not sure, I'll use Environment file and you can see how it works. And I think I'll exclude ufdbsignal for now. setuid binaries can be a security risk, and I don't see a compelling argument for it's use. Test RPMS coming soon. Ok, give it a whirl. https://fedorapeople.org/~limb/ufdbGuard/ufdbGuard-1.33.3-1.el7.centos.x86_64.rpm Should these: /var/lib/ufdbguard/logs move to /var/log? Didn't want to do any file moving eh? :-) Le sigh. No, not really. I've updated the RPM to use /var/log/ufdbguard/. Same URL. There are a couple of privacy-concerning issues that might not be appropriate for an EPEL package. In /etc/ufdbguard/ufdbGuard.conf:
analyse-uncategorised-urls
upload-crash-reports
I'm getting the following SELinux AVCs:
type=AVC msg=audit(1499447735.881:47180): avc: denied { write } for pid=9333 comm="ufdbgclient" name="ufdbguardd-03977" dev="dm-4" ino=339 scontext=system_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file
As for moving files to support upgrades from the ufdbguard supplied RPM, if you care, I had to move /var/ufdbguard/blacklists/* to /var/lib/ufdbguard/blacklists/*.
Worth noting that the ufdbguard supplied rpm did not have /var/ufdbguard/blacklists/security/cacerts in it. Not sure what that is [used for].
I suppose also, during an upgrade from the ufdbguard installed RPM, the existing service(s) should be stopped since their initscript will be gone post-upgrade, and I guess squid should be restarted/reloaded to restart the ufdbgclient services.
The /etc/init.d/ufdb seems to set:
RUNAS="ufdb"
which results in "-U $RUNAS" being passed to ufdbguardd on start up. I don't see anything in the unit file reflecting that.
On the topic of /etc/sysconfig/ufdbguard, $UFDB_OPTIONS from that file is supposed to be added as options to the /usr/sbin/ufdbguardd as well as having $RUNAS being added with "-U", even though it seems to be duplicated by /etc/init.d/ufdb.
This is probably the issues you were referring to in comment #7.
Probably the AVCs are the most important issue at the moment.
There seems to also be an issue where it won't start up from systemd -- or rather, it does, but soon after dies but I can start it on the command-line with the same arguments and it runs. I'm seeing what I can figure out about that... In the unit file the Type needs to be forking, not simple. So are we done with trying to get this to work? Shall I just roll back to the upstream's RPM since this one is not working? Should that socket even be in /tmp? Wouldn't /run be a better place? Sorry for the delay, I got busy again. I should have time to put together another attempt today. Ok, new version, same URL. Fixed the ufdb user creation, unit file, etc. I'm wondering if it would be better to run as the squid user instead. The ufdbguardd-03977 socket is still in /tmp. Should that be in /tmp or [/var]/run? Still obviously getting the SELinux AVCs. That's not necessarily a problem, other things put sockets in /tmp. I installed and ran this on f26 and got no AVCs. I've also not modified the configs at all, not ever run ufdb on this machine. Are you able to test on another, fresh CO7 machine/vm? (In reply to Gwyn Ciesla from comment #21) > That's not necessarily a problem, other things put sockets in /tmp. Just because others put sockets there doesn't mean it's correct though. http://www.linuxbase.org/betaspecs/fhs/fhs/ch03s15.html: 3.15. /run : Run-time variable data System programs that maintain transient UNIX-domain sockets must place them in this directory or an appropriate subdirectory as outlined above. > I > installed and ran this on f26 and got no AVCs. Do you have SELinux in enforcing mode? Because: https://bugzilla.redhat.com/show_bug.cgi?id=1264664 > Are you able to test on another, fresh CO7 machine/vm? I don't have another CentOS machine to test on, no. But if policy on one machine is lacking permissions, I would expect any other machine to have the same problems. (In reply to Gwyn Ciesla from comment #21) > I > installed and ran this on f26 and got no AVCs. Maybe F26 has policy for ufdb but EL7 doesn't? I'm not sure how one would research that though. Anyway I created a local policy for it:
module ufdbGuard_local 1.0;
require {
type tmp_t;
type squid_t;
class sock_file write;
}
#============= squid_t ==============
#!!!! WARNING 'squid_t' is not allowed to write or create to tmp_t. Change the label to squid_tmp_t.
allow squid_t tmp_t:sock_file write;
Would be nice to get this into the EL7 policy.
(In reply to Gwyn Ciesla from comment #10) > Ok, give it a whirl. > > https://fedorapeople.org/~limb/ufdbGuard/ufdbGuard-1.33.3-1.el7.centos. > x86_64.rpm Did this make it into any sort of distribution (Fedora, EPEL, EL, etc.)? The last installation I have of it on my EL7 machine is from the commandline which is probably from the above. Not so far. But here's an updated 1.33.6: https://fedorapeople.org/~limb/ufdbGuard/ufdbGuard-1.33.6-1.el7.x86_64.rpm FEDORA-EPEL-2020-f50061e899 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f50061e899 FEDORA-EPEL-2020-0964ecd023 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0964ecd023 FEDORA-2020-a3d4990bd0 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3d4990bd0 FEDORA-EPEL-2020-f50061e899 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f50061e899 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-0964ecd023 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0964ecd023 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-a3d4990bd0 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-a3d4990bd0 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3d4990bd0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-a3d4990bd0 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2020-f50061e899 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2020-0964ecd023 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report. |