Hi,

Le 03/11/2010 01:24, John Horne a écrit :
> On Tue, 2010-11-02 at 21:21 +0100, Patrick Gouin wrote:
>    
>> Maybe there should be a different treatment for --enable depending on
>> whether the test is a grouped one or not
>>
>>      
> There is a difference. If you enable a specific test name, then the test
> is run. If you enable a grouped test name, then only those tests which
> are not disabled in the config file are run. However, see below about
> how 'all' works. It is not a specific test name (so the config file is
> looked at for disabled tests), and will cause any other test names to be
> ignored.
>    
I was unclear, I mean RHK could apply the DISABLE_TESTS config option to
the grouped test (or all option) given on the command line but not to 
the elementary tests.
Not sure it's clearer :)
>>>      rkhunter --enable hidden_procs
>>>
>>>        
>> This works even if hidden_procs is disabled in the config file.
>>      
> Yes, because it is a specific test name - not a grouped one - and you
> are explicitly telling RKH to run it. RKH will try and work out what you
> want to do, and in this instance because you have given the specific
> test name it assumes you actually want to run the test (despite it
> normally being disabled).
>    
I was referring to the two previous lines, that you have snipped, where 
you said to modify
the config file before running the command.
>> On the other hand, I suspect that if someone do
>>          rkhunter --enable all,hidden_procs
>> he knows what he is doing and do have 'unhide' or 'unhide.rb'
>> installed.
>>
>>      
> In this case though RKH sees the 'all'. Once this is seen, all the other
> test names are ignored. As such this becomes '--enable all'. RKH does
> not treat 'all' as a specific test name, and so will look in the config
> file to see which tests are disabled. Since 'hidden_procs' is disabled,
> it does not run.
>
>
>    
>> I did some more testing with the default config file of RKH let
>> unmodified (suspscan is disabled)
>>
>>          rkhunter --enable malware,suspscan
>>
>> run the the suspscan test but
>>
>>         rkhunter --enable all,suspscan
>>
>> don't run it.
>>
>>      
> Yes, see above about 'all'.
>
>    
>> Why is there a difference between the grouped test malware and the
>> "super-grouped"  test all ?
>>
>>      
> See above. 'all' is not a specific test name, and so RKH will check
> further to see if a test is disabled.
>
> When using the '--enable' and '--disable' options it must be remembered
> that RKH will run non-specific tests according to the rules in the
> configuration file (that is, it won't run a disabled test). With the
> '--disable' option there is a --nocf' option to indicate that the config
> file is not to be used, and only the specified disabled tests are to be
> disabled.
>
> Some examples:
>
>         --enable hidden_procs
> runs the test whether it is disabled or not because it is a specific
> test name.
>
>         --enable malware
> runs the malware tests provided they are not disabled in the config file
> (because 'malware' is not a specific test name). As such hidden_procs
> does not run.
>
>         --enable all
> runs all tests that have not been disabled in the config file. 'all' is
> not a specific test name.
>
>         --enable malware,all,hidden_procs
> exactly the same as '--enable all'.
>
>         --enable all --disable none
> runs all tests.
>
>         --disable none
> runs all tests (because the default config file enables all tests).
>
>         --enable malware --disable other_malware
> runs the 'malware' tests except for 'other_malware' and any other tests
> disabled in the config file.
>
>         --enable malware,suspscan --disable deleted_files
> runs the malware tests, including 'suspscan' because it is a specific
> test name, but not 'deleted_files' or any other tests disabled in the
> config file.
>
>         --enable malware --disable deleted_files --nocf
> runs all the malware tests except for 'deleted_files'. Because '--nocf'
> is used, the config file is not looked at.
>
>         --enable malware --nocf
> this is the same as '--enable malware'. The '--nocf' option only works
> when used with '--disable'.
>
>         --enable malware,suspscan --disable suspscan
> runs the malware tests except for 'suspscan' and any other tests
> disabled in the config file. 'suspscan' does not run because, despite
> being explicitly enabled, it has also been explicitly disabled. If you
> tell RKH not to run a test, it will not run it regardless of what has
> been enabled. In effect, 'disable' overrides 'enable'.
>    
This is where our philosophy differs. I tend to prefer that 'enable' 
overrides 'disable'.
But I have already adapted myself :)
>         --enable suspscan --disable suspscan
>         --enable malware --disable malware
> both of these will give an error ('no tests to run').
>
>     --enable malware --disable other_malware,deleted_files,running_procs
> This will all give an error ('no tests to run'). The '--disable' tests
> are all part of 'malware', and when combined with the default disabled
> tests in the config file, there are no tests left to run.
>
>         --enable suspscan --disable malware
> will give an error ('no tests to run'). 'suspscan' does not run, despite
> being explicitly enabled, because 'malware', which includes the suspscan
> test, has been explicitly disabled. As said above, if a test is
> explicitly disabled, then it will not run regardless of what has been
> enabled.
>
> Note: although 'malware' is a grouped name, when it is disabled it
> applies to all the specific tests within it. It is not possible to
> enable a specific part of a disabled group. The converse, however, is
> true - it is possible to enable a group, and disable specific parts of
> it.
>
>         --enable none
>         --disable all
> both of these will give an error.
>
>    
Many thanks for this long response.
I think this whole explanation is very nice. You should add it to what 
is already said
in the README and/or to the wiki.
It would be a pity to only let it in the mailing list archive.
>    
>> My distro recently changes from syslog to rsyslog. RKH correctly find
>> it running.
>> Due to my lack of attention and/or my laziness. the old syslog.conf
>> is still in /etc as the new rsyslog.conf.
>> This make RKH reports :
>>
>> [20:21:26]   Checking for running syslog daemon              [ Found ]
>> [20:21:27]   Checking for syslog configuration file          [ Found ]
>> [20:21:27] Info: Found syslog configuration file: /etc/syslog.conf
>>
>> RKH should probably looks only for the config file corresponding to
>> the syslog utility it found just before.
>>
>>      
> I don't quite follow this. Are you saying:
>    
Sorry for my poor English :s
> 1) that /etc/syslog.conf is a symbolic link to /etc/rsyslog.conf, and
> that RKH should show the true file name (rsyslog.conf) rather than the
> link name?
>    
That's not this case.
> 2) or that both /etc/syslog.conf and /etc/rsyslog.conf exist as files,
> but the 'syslogd' daemon does not exist, and as such RKH should instead
> show the /etc/rsyslog.conf file because rsyslogd is running?
>
>    
That's exactly what I mean except I would have written check instead of 
show..
> John.
>    
Thanks again,

Patrick.

------------------------------------------------------------------------------
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware, 
phishing sites, and compromised hosts - saving your company time, 
money, and embarrassment.   Learn More! 
http://p.sf.net/sfu/hpdev2dev-nov
_______________________________________________
Rkhunter-users mailing list
Rkhunter-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkhunter-users

Reply via email to