Bug 1426863 - unmaintained? package ufdbguard instead?
Summary: unmaintained? package ufdbguard instead?
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: squidGuard
Version: epel7
Hardware: x86_64
OS: All
unspecified
high
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-25 22:19 UTC by Brian J. Murrell
Modified: 2020-07-30 18:19 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-23 01:06:13 UTC
Type: Bug


Attachments (Terms of Use)

Description Brian J. Murrell 2017-02-25 22:19:41 UTC
squidguard is starting to look very unmaintained at this point.  Even their latest "Devel" release is over 2 years old:

http://www.squidguard.org/Downloads/Devel/

Latest stable release is 8 years old.

Is it worth considering ufdbguard as a replacement, at this point?

While the maintainers of ufdbguard are trying to make money licencing block lists for ufdbguard, ufdbguard is itself, GPL2 as far as I can tell.

Comment 1 Brian J. Murrell 2017-07-07 11:06:21 UTC
Is this package SOOOOO un-maintained that even bug reports about it are not being dealt with?

Comment 2 Gwyn Ciesla 2017-07-07 12:58:48 UTC
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.

Comment 3 Brian J. Murrell 2017-07-07 13:02:44 UTC
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.

Comment 4 Gwyn Ciesla 2017-07-07 14:08:39 UTC
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.

Comment 5 Brian J. Murrell 2017-07-07 14:33:05 UTC
I'm using CentOS 7 on x86_64.

Comment 6 Gwyn Ciesla 2017-07-07 15:13:58 UTC
Cool.  I'll make it work for that as well.

Is the 6755 perm on /usr/sbin/ufdbsignal necessary?

Comment 7 Gwyn Ciesla 2017-07-07 15:32:49 UTC
Also, how important is it to support the /etc/sysconfig file?  It's possible with systemd but it's a pain.

Comment 8 Brian J. Murrell 2017-07-07 15:48:40 UTC
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.

Comment 9 Gwyn Ciesla 2017-07-07 15:53:13 UTC
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.

Comment 11 Brian J. Murrell 2017-07-07 16:18:15 UTC
Should these:

/var/lib/ufdbguard/logs

move to /var/log?

Didn't want to do any file moving eh?  :-)

Comment 12 Gwyn Ciesla 2017-07-07 16:26:27 UTC
Le sigh.

No, not really.

I've updated the RPM to use /var/log/ufdbguard/.

Same URL.

Comment 13 Brian J. Murrell 2017-07-07 17:18:36 UTC
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.

Comment 14 Brian J. Murrell 2017-07-07 17:39:28 UTC
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...

Comment 15 Brian J. Murrell 2017-07-07 17:46:47 UTC
In the unit file the Type needs to be forking, not simple.

Comment 16 Brian J. Murrell 2017-07-11 13:17:39 UTC
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?

Comment 17 Brian J. Murrell 2017-07-11 14:44:01 UTC
Should that socket even be in /tmp?  Wouldn't /run be a better place?

Comment 18 Gwyn Ciesla 2017-07-11 14:47:44 UTC
Sorry for the delay, I got busy again.  I should have time to put together another attempt today.

Comment 19 Gwyn Ciesla 2017-07-11 14:59:52 UTC
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.

Comment 20 Brian J. Murrell 2017-07-11 17:56:05 UTC
The ufdbguardd-03977 socket is still in /tmp.  Should that be in /tmp or [/var]/run?

Still obviously getting the SELinux AVCs.

Comment 21 Gwyn Ciesla 2017-07-11 18:11:14 UTC
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?

Comment 22 Brian J. Murrell 2017-07-11 18:42:05 UTC
(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.

Comment 23 Brian J. Murrell 2017-07-11 18:43:37 UTC
(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.

Comment 24 Brian J. Murrell 2017-07-11 18:54:31 UTC
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.

Comment 25 Brian J. Murrell 2018-05-28 17:00:16 UTC
(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.

Comment 26 Gwyn Ciesla 2018-05-29 15:21:33 UTC
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

Comment 28 Fedora Update System 2020-07-14 17:24:30 UTC
FEDORA-EPEL-2020-f50061e899 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f50061e899

Comment 29 Fedora Update System 2020-07-14 17:24:30 UTC
FEDORA-EPEL-2020-0964ecd023 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0964ecd023

Comment 30 Fedora Update System 2020-07-14 17:24:31 UTC
FEDORA-2020-a3d4990bd0 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3d4990bd0

Comment 31 Fedora Update System 2020-07-15 01:28:07 UTC
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.

Comment 32 Fedora Update System 2020-07-15 01:37:43 UTC
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.

Comment 33 Fedora Update System 2020-07-15 02:01:06 UTC
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.

Comment 34 Fedora Update System 2020-07-23 01:06:13 UTC
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.

Comment 35 Fedora Update System 2020-07-30 18:13:08 UTC
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.

Comment 36 Fedora Update System 2020-07-30 18:19:21 UTC
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.


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