#129 wildcards in ALLOWPROCDELFILE do not work

[Cálestyo]

Hi.

ALLOWPROCDELFILE is described like this:

Allow the specified process to use deleted files. The process name may be

followed by a colon-separated list of full pathnames. The process will then

only be whitelisted if it is using one of the given files. For example:

ALLOWPROCDELFILE=/usr/libexec/gconfd-2:/tmp/abc:/var/tmp/xyz

This option may be specified more than once. It may also use wildcards, but

only in the file names.

The default value is the null string.

ALLOWPROCDELFILE=/sbin/cardmgr

ALLOWPROCDELFILE=/usr/sbin/mysqld:/tmp/ib*

1) "It may also use wildcards, but only in the file names." is ambiguous, since both are file names, the one from the process and the one from the deleted files.
But the example would imply that the wildcard can be used on deleted files (which is what makes sense, since these are usually tempfiles with a random name).

2) Would a wildcard on any file i.e. "foo:/tmp/*" work?

Most important though

3) It doesn't work at all:
I've tried e.g.:
ALLOWPROCDELFILE=/usr/lib/gnome-terminal/gnome-terminal-server:/tmp/#
ALLOWPROCDELFILE=/usr/lib/iceweasel/iceweasel:/var/tmp/etilqs_
ALLOWPROCDELFILE=/bin/dash:/tmp/*

but nothing is whitelisted (only when I remove the colon and everything afterwards, then it is).

The respective section in the code seems to be in malware_checks():
13386 if [ "${PROC}" = "${RKHTMPVAR2}" ]; then
13387 if [ $PROCDELFILES_GIVEN -eq 1 ]; then
13388 RKHTMPVAR3=`echo "${RKHTMPVAR}" | awk -F ':/' '{ for (i = 2; i <= NF; i++) { a[i] = $i } } END { for (i in a) { print "/ " a[i] } }'
13389
=> here RKHTMPVAR3 holds the correct value (i.e. everything after ":")

13390 # Now expand the deleted file pathnames.
13391 RKHTMPVAR3=expand_paths RKHTMPVAR3
=> but I guess this simply don't work, expand_paths can only work on existing files while here we have a deleted file.

13392
13393 # We must reset the IFS because 'expand_paths' sets it to the default.

Cheers,
Chris.

[Cálestyo]

Sorry for the ugly formatting... SF sucks... ^^
the numbers are line numbers, though, from version 1.4.2

[Christian Burger]

Sorry for the ugly formatting... SF sucks... ^^

Tried the "Preview" button? It can help avoiding those formatting errors. So is the "Formatting Help" button, which tells you how to insert preformatted text: By indentation. :)

Anyway, same problem here, came to the same conclusion "problem is that globbing does not work on deleted file". Fixed it by fiddling with the generation of FNAMEGREP in line 13396.

Now "?" is replaced by "[^/]" and "*" is replaced by "[^/]*". The resulting grep command seems to work. But it does not restrict the process to the filename. You can actually glob directories as well now.

The attached patch is my fix for 1.4.2. Though, I didn't check on a bigger scale if it introduces other problems. Someone should probably look it over.

In general: If rkhunter is using grep in the end, wouldn't it had been easier/better to pass through the capability of using regular expressions to ALLOWPROCDELFILE? I don't know, I'm just asking.

[John Horne]

Are you reporting this problem against the latest CVS version? There is a fix for the option already in there.

[Cálestyo]

Hi John.

This was against 1.4.2 from Debian.

Cheers,
Chris.

[John Horne]

Fixed in CVS.

[Christian Burger]

On Sunday 26 October 2014 21:50:12 you wrote:

Are you reporting this problem against the latest CVS version? There is a
fix for the option already in there.

Argh, I am an idiot. I forgot to check that, sorry. But I realize now my patch was incomplete anyway.

I think that using expand_path does not only not work as Cálestyo stated, it actually interferes when handling deleted files -- see test cases 2. and 3. below.

I made three test case in the form of one bash script, so there is an objective base to verify the problem I see and I thought this bug report would address. Those are the scenarios:

1. no existing file is matching the glob pattern (using *)
2. an existing file is matching the glob pattern (using *), thus potenially masking the hidden file in case of globbing
3. an existing file is matching one of two given glob patterns (using ?), similar to 2., but with more than one pattern

The latest CVS version 1.526 of rkhunter fails all three tests. After the patch is applied rkhunter succeeds in running the test cases.

The new patch it based on 1.526 of rkhunter. The second patch adds the above described test script to files/testing/rkhunter-test.bash.

Here is a short explanation for test case 2):
If you for example

1. allow /dev/pts/*,
2. the process uses /dev/pts/1 and
3. the file was deleted, but
4. there is still /dev/pts/2

then globbing will expand it to /dev/pts/2 and this will not match /dev/pts/1 which was the original intention of the given pattern at 1.

And regarding the manual; as Cálestyo already stated the manual might be a bit ambiguous, when stating:

# This option may be specified more than once. It may also use wildcards, but
# only in the file names.

I am not sure what you mean by 'file names', does it mean

1. the last part of the path to each file (actual filename/basename),
   differentiating from the full path of the whitelisted files or does it mean
2. The full path of each whitelisted file, differentiating from the executable filename.

I assumed you meant 2. Maybe something like this would be less ambiguous:

# This option may be specified more than once. It may also use wildcards, but 
# not in the path pointing to the process' executable (first argument).

With the attached patch, /foo/bar*.d/baz* should match an open file, but deleted file /foo/bar_bla.d/bazbuz, even if the containing directory /foo/bar_bla.d/ was deleted. This is an edge case, but actually not matching directories would make the handling more complicated -- as far as I see.

[John Horne]

This should now be fixed in the current CVS version.
Bug #114 will have any further details.