#16 Speed up the properties db update?

main
closed-fixed
Rkhunter (37)
5
2008-12-10
2008-03-22
No

Hi,

Here is a wishlist report sent to the Debian BTS by Francois Marier - original report can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472114

==

Hi,

I understand that this is not strictly speaking a problem with rkhunter or the packaging
(hence the wishlist severity). However, on my laptop, doing the property update at the
end of each apt run is very slow. When apt-get installing small packages, it often takes
more time to update the properties than download and install the package.

Is there a way that we could speed this up? Either by priming the cache in a clever way
with readahead, or by being smarter about which files to re-hash.

Maybe it would make sense to create a "quick" property update where rkhunter would look
at each file and if the timestamp hasn't changed just assume that the hash is still the
same.

==

Is there any work planned in this way?

Cheers,
Julien

Discussion

  • John Horne

    John Horne - 2008-03-22

    Logged In: YES
    user_id=665381
    Originator: NO

    First of all, checking the timestamp and assuming the file hash is the same is a *REALLY BAD* idea. It won't happen. A hacker can easily change a file and then just reset the timestamp, no problem.

    I think you need to define a bit more what 'very slow' is? What is the spec of the laptop? Does the users config file use the database manager or just a hash function (which one)?

    John.

     
  • Francois Marier

    Francois Marier - 2008-03-23

    Logged In: YES
    user_id=54366
    Originator: NO

    Sorry, maybe I wasn't clear with the timestamp checking suggestion. I was definitely not suggesting that rkhunter check for timestamps instead of hashes when it does its nightly scan or when we force it to update all properties. Instead, here's what I had in mind.

    Currently, we have this:
    1- I install rkhunter and it does a full propupd when it's installed to get initial hashes
    2- I install a new package using apt-get and it triggers a full propupd in case some of the tracked files have changed. This updates all hashes in the rkhutner configuration
    3- Every night, rkhunter computes the hash of each tracked file and compares it to its internal list.

    What I am suggesting is changing step 2 so that apt-get does a "quick propupd" skipping the hash computation whenever the file hasn't changed. This means that the hashes are still fully computed in step 1 and so the nightly run will compare its computed hashes against the list made in step 1. This "quick update" would not replace the current "--propupd" behaviour.

    Now, that said, when I originally filed the bug report, I was using the DPKG package manager setting and that made --propupd about 4 times slower (24s as opposed to 6s for NONE). I have switched to NONE now and so it's much faster.

    I guess it puts this bug into the not-so-important-anymore category :)

    Francois

     
  • Julien Valroff

    Julien Valroff - 2008-03-23

    Logged In: YES
    user_id=464661
    Originator: YES

    Hi John,

    Would it be possible for you to add an option to rkhunter so that it is possible to update or add the properties of the file given as an argument?

    As an example, if the package containing /usr/bin/useradd is updated, it would be great that only useradd properties are updated (something like `rkhunter --filepropupd useradd'). If it is a newly installed file, its properties could be appended to the existing.

    That would also secure the process when updating automatically the file properties db after packages upgrade.

    Cheers,
    Julien

     
  • John Horne

    John Horne - 2008-04-05

    Logged In: YES
    user_id=665381
    Originator: NO

    Okay, I see what is being asked for here.

    In theory I see no problem with this. I have some other ideas about the properties stuff, so when I get to that bit of code I'll see what can be done.

    John.

     
  • John Horne

    John Horne - 2008-04-05
    • assigned_to: nobody --> jhorne
     
  • Julien Valroff

    Julien Valroff - 2008-04-05

    Logged In: YES
    user_id=464661
    Originator: YES

    Hi John,

    Great. Thanks for your work.

    Please keep me informed if you want me to test something.

    Cheers,
    Julien

     
  • Siim Põder

    Siim Põder - 2008-08-23

    Logged In: YES
    user_id=2191568
    Originator: NO

    jhorne, IMO the suggestion is not to assume that constant timestamp means an unchanged hash. the suggestion is, that if a package is being updated, then skip the update if the timestamp is the same.

    the only thing that an attacker would gain from this is, that they could modify a file while keeping it's timestamp and postpone the detection of the event until the nightly scan. as the update during running the package manager is not meant for detection, but rather updating to the changed system, it wouldn't really decrease the security (as most days people do not run apt-get so you can't depend on that).

    the only downside would be, that an attacker could be fairly confident, that if they restore any changes for the nightly scan, they are not going to be noticed (from that angle, anywise) while the package manager check could flush out that. but then again, if you are restoring files for the check to occur, you could as well trigger a restore operation for apt-get as well, so it wouldn't probably really help that much.

     
  • Julien Valroff

    Julien Valroff - 2008-08-24

    Logged In: YES
    user_id=464661
    Originator: YES

    widow: actually, the suggestion is to *only* update the data for files being updated, leaving alone the other data.
    The aim is to speed up the update process, whatever means to reach this goal could be ok, to the condition it respects the global security of the system.

    Cheers,
    Julien

     
  • John Horne

    John Horne - 2008-09-07

    Logged In: YES
    user_id=665381
    Originator: NO

    Can I ask how you would know which files belong to which updated package?

    Under Fedora a file such as /usr/bin/awk belongs to the 'gawk' package, /usr/bin/file belongs to the 'file' package, but /usr/bin/wc belongs to the 'coreutils' package which provides many of the basic commands. As such if coreutils was updated, I could not say which files were updated without asking the package manager what files are in the coreutils package (the same with awk and file actually). The point is that I would have to spend a fair amount of time finding out the filenames, when I might just as well have told RKH to update the whole database.

    Whether the new code will support the 'adding' of new files to the properties database I do not know yet. That will require a bit more thought, but at present (in my version) only files that already exist in the database can be updated. I doubt adding new entries will be allowed.

     
  • John Horne

    John Horne - 2008-09-11

    Fixed in CVS. It does however require more testing. The man page contains details.
    The '--propupd' option can be followed by a filename, a directory or a package name. This can be a list of names. If using a package manager, you must run 'rkhunter --propupd' (with no options) first.

    John.

     
  • Julien Valroff

    Julien Valroff - 2008-09-14

    Hi,

    Thank you for your work on this feature!

    Cheers,
    Julien

     
  • unSpawn

    unSpawn - 2008-12-10

    Since John added this is in CVS I'll close this ticket.

     
  • unSpawn

    unSpawn - 2008-12-10
    • status: open --> closed-fixed
     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks