#13 Add --jail option to enable tests relevant to chroot jail

main
closed
unSpawn
Rkhunter (37)
5
2008-02-24
2007-10-20
No

It would be useful to be able to quickly enable only those tests that are relevant to testing a chroot jail using the --rootdir option.

I'm not sure if this would be a shortcut to running --enable with specific arguments, or if its more complex than that, and when testing a jail you want to still run some tests but surpress particular warnings (e.g. On testings for the Phalanx Rootkit (strings) I got a messsage:

[ Warning ]
[07:02:09] The file '/web/bin/hostname' does not exist!

If rkhunter knew it was tesing the chroot jail /web, it could know to run /bin/hostname instead.

Discussion

  • unSpawn

    unSpawn - 2007-10-20

    Logged In: YES
    user_id=600864
    Originator: NO

    If RKH was run 1) inside the chroot jail and 2) the jail was set up properly then it would find '/bin/hostname' as '/bin/hostname'. AFAIK the only way RKH can find '/web/bin/hostname' is if 1) it's run outside the jail and 2) ''/web/bin/' is in your $PATH (and 3) precedes '/bin'). If you determined this is not the case I would appeciate if you attach the debuglog from running RKH in debug mode. Please do bzip2 the debuglog as it tends to be large.
    Thanks for your support.

    Regards, unSpawn

     
  • unSpawn

    unSpawn - 2007-10-20
    • labels: --> Rkhunter
    • milestone: --> main
    • assigned_to: nobody --> unspawn
     
  • The Story Teller

    Logged In: YES
    user_id=1321152
    Originator: YES

    I hadn't looked at the conf file options before posting - having done so, I think the best way for me to scan the jail is to add its folders to the directories scanned instead of running rkhunter twice, once for inside and once for outside. That would prevent the superious tests being performed.

    Regarding the specific hostname problem, /bin/hostname does not exist inside the jail. I was running rkhunter outside the jail but scanning with --rootdir=/web. It therefore scanned /web/bin instead of scanning /bin and searched for /bin/hostname in /web/bin/hostname which it did not find. I don't know enough about the testing to know why it is looking for it: If it needs to test the copy of hostname inside for alterations then this is correct behaviour. If it needs to run hostname in order to perform the test, then I would suggest it should run /bin/hostname rather than taking the rootdir into account and trying to run /web/bin/hostname.

    /web/bin is not in the $PATH when outside the jail.

    /web/bin is not in the $PATH when outside the jail. The problem is not that rkhunter finds /web/bin/hostname - it is that is

    File Added: rkhunter-debug.bz2

     
  • John Horne

    John Horne - 2007-10-22

    Logged In: YES
    user_id=665381
    Originator: NO

    I think there are perhaps two things you are asking here, rather than just one.

    1) Use of 'hostname' command:
    First, RKH is correct in issuing the above warning during the Phalanx test, because the test is of the 'hostname' command itself. There would be no point in running the test (in your situation) on '/bin/hostname' since all that would do is test for Phalanx on your running system and not the hostname within the chroot jail. So RKH must test the command using the pathname specified by the '--rootdir' option.

    Secondly, other tests will use the 'hostname' command - for example, to ensure that the system hostname has been set. Again, there is no point in testing '/bin/hostname', the test must include the '--rootdir' pathname.

    2) Use of the '--rootdir' option:
    This option was initially devised to allow users to locally, or remotely, mount an infected system disk (read-only obviously). Hence, all the required files of a working system would be available on that mount point. By using the '--rootdir' option a user could run RKH but tell it to look for relevant files (such as '/bin/hostname') within that mount point file system.

    In theory I guess this could also be achieved using a chroot jail. But, again, this assumes that within the jail is a complete system. RKH could then be run either inside or outside of the jail (using the '--rootdir' option if run outside).

    As far as I can tell in your case this is not so - you do not have a complete system within the jail.
    To that extent I am wondering what it is you are trying to do? You say 'enable only those tests that are relevant to testing a chroot jail', but testing what? If the jail is not a complete system, then what is the point of it, and what is it that RKH is supposed to be testing?

    John.

     
  • The Story Teller

    Logged In: YES
    user_id=1321152
    Originator: YES

    On point 1:

    If the test is on hostname itself, I agree it should test the one inside the jail, and is behaving correctly. However, if the --jail flag I am requesting were added, it should not generate any warning when the file is missing and the flag is present, as there is no need to warn that hostname is missing on a known-to-be-incomplete system. If hostname did exist, it should still test it for problems.

    On point 2:

    I do, as you say, have an incomplete system within the jail - just a web server, PHP and the supporting files required.

    My purpose in running rkhunter against the jail is to detect if an attack has taken place using the web server or PHP as an attack vector, and the presence of the jail has sucessfully redirected to the attack to compromise a file inside the jail instead of the one outside. This may well result in an unsucessful installation of the rootkit, but is evidence that an attack has taken place. As I said in an earlier comment, I discovered after posting this feature request that I could possibly achieve this by running rkhunter on my real root folder and specifying addtional bin directories to check. Being new to the product, I'm not sure if that offers the same level of detection, or if running rkhunter a second time with --rootdir set to the location of the jail will perform additional tests not provided for by additional bin folders. If running a second time generates no additional benefits over using additional bin folder, then I withdraw this request, as the feature serves no purpose.

    On reflection 'enable only those tests that are relevant to testing a chroot jail' was a bad choice of words. I meant that the presence of the --jail argument would tell rkhunter that it should expect the system it is being run against to be incomplete, and it should not generate warning or error messages about problems caused by the incompleteness (such as not being able to find /bin/hostname) but silently ignore such problems. When run on a complete system, I understand it is sensible to generate warnings about important system files being missing, but if it knows it is running against the incomplete system of a chroot jail, it would be an improvement to only generate warnings and errors relating to the evidence of malicious code, rather than informing the user about missing files.

    The addition of the --jail flag would allow the --rootdir argument to be used for the purpose it was originally envisaged of mounting other filesystems, and the additional purpose of testing jails.

    Whether when the --jail flag is used and a file needed to perform a test is not available inside the jail a copy from the host system (such as running /bin/hostname to determine the hostname for a test) should happen is probably something that needs to be determined on a case-by-case basis.

     
  • unSpawn

    unSpawn - 2008-02-24

    Logged In: YES
    user_id=600864
    Originator: NO

    L.S.

    Pondering this request I come to the conclusion that disabling alerting, based on what you ask for, does not appear to be within the scope of RKH IMHO: since you know you're working with incomplete setups you probably know which warnings you can discard yourself. So I'll close this issue since no other people have problems that would be fixed by this or have requests that are similar to this.

    Regards, unSpawn

     
  • unSpawn

    unSpawn - 2008-02-24
    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks