#29 [PATCH]: auto-whitelist xinetd.d services from RPM

[Jan Iven]

Intention is to cut down on false positives from enabled "xinetd"
services. These can already be whitelisted manually, but lets assume
that anything installed directly by package manager (RPM) is OK -
either because the RPM already contains an "enabled" service or
because the file is clearly marked as "configurable" (so enabling the
service is somehow an expected action).

Should still complain about weird additions/backdoors, of course.

[John Horne]

"lets assume that anything installed directly by package manager (RPM) is OK"

I'm not sure that that is something we do want to assume though. I would rather have RKH tell me that something has changed, and that, yes, I have to run 'RKH --propupd' to, in effect, verify that it is okay.

[Jan Iven]

[background: My intent is to roll out rkhunter as widely as possible, and treat any warning as a serious security incident, instead of a thing that needs investigation but might be harmless. In thta scenario, local admins are not required to modify rkhunter configuration files].

The rationale for "ignoring" such RPM-installed xinetd service would be that these are not directly "backdoors" themselves. Running "authd" or FTP increase exposure but would typically not be giving direct and immediate root access. In addition, by using the package manager to verify the file I make it less likely that a previously-whitelisted service is being redirected to some malicious replacement.

I could suggest several things:
* a generic xinetd whitelist entry "RPM" in the config file (so by default rkhunter behaviour doesn't change, but I get a generic item to modify in our configuration, instead of whitelesting every singe service ever possibly installed).
* explcictly filter "evil" services (rsh/rlogin) that present a higher risk
* more thorough check on the xinetd file (e.g. to-be-started service needs to come from same RPM as file in xinted.d/, and has to pass verification)..

Please let me know if any of these would increase chances for the patch to be accepted.
Cheers
Jan

[Jan Iven]

(previous version had a minor error)

[Jan Iven]

Attached patch implements a whitelisting on whether the xinetd file is from RPM, and is either unmodified (so comes "enabled by default"), or clearly marked as "configuration" (in which case enabling is supposed to be OK).

Clearly a shift to "less false positives" at the expense of not getting information about your system.

[unSpawn]

As noted in John's comment we would rather allow RKH to tell about things that have changed. We will not apply this patch. As always thanks for your continued support.