|
From: adrian g. <adr...@gm...> - 2008-10-30 07:45:55
|
hi, thank you for your explanation. i tried the measurereq extension on some applications, and i am thinking of trying to modify IMA to hook on every file open and see how much overhead that would bring. can you please give me some tips on where to modify the patch file to do so? i looked at the 2.6.26.3 ima patch file, and i guess that ima_measure_module is called to measure modules, and ima_file_mmap for measuring executables. if i want to measure every file, exceutables and modules would be a subset and it seems that i would have to modify quite a lot of code which i am not confident i will be able to do so correctly. thanks - adrian On Fri, Oct 17, 2008 at 9:41 PM, Reiner Sailer <sa...@us...> wrote: > Hi Adrian, > > there are several levels of guarantees we can distinguish: load-time, > application-start-time, system-start-time > > a) if you change the application to measure the file right before it is > used, IMA offers TOMTOU protection, i.e., the measured file is monitored in > the kernel and if anybody writes to it before the application closes it, > then a violation is reported in the measurement list > --> what you measure is what you read [strongest guarantee IMA offers for > user space apps = load-time guarantee] > > b) if you add a wrapper to the application that simply measures all input > files before the application starts, then an attacker can change those files > between the start-up of the application and the time when the application > consumes those files > --> what you measure is what is in the file at app startup [app start time > guarantee], clearly the longer an application runs, the weaker the > guarantees, especially consider that some daemons offer to send a signal to > re-read quite important configuration files > > c) if you measure important files at system start, then you get protection > from offline changes that can happen between boots or between TCGGrub/IMA > protected boots (the TCG extended GRUB offers to do this very early at boot > time by specifying those files in the grub.conf; alternatively, the kernel > could simply have a list of those files and measure them once the file > systems are mounted into the kernel) > --> what you measure is what the file is at boot time (very weak if the > system is up very long; still much much better than nothing = current state) > --> still detects trap-doored daemons that are changed on disk etc. and > many other things that attack the system in a way that is visible at boot > time > > TO your questions: > Hooking into every file open (not only executables) from within the kernel > is inducing some more overhead. Right now, overhead is negligible. If you > hook into every file operation you have two problems: > a) considerably more overhead > b) compare for each r/x file-open if the file name is in a list (you need > fully qualified names here) is adding even more overhead > > Other than that, and if the list is very small, you could pay the price of > measuring at every open. This way you get around changing apps while still > getting load-time guarantees. Of course you pay with the cost of > checking/measuring the files even if they are opened by an application that > does not interpret them (e.g., editor, ...). > > Reiner > > > [image: Inactive hide details for "adrian golding" ---10/17/2008 02:39:41 > AM---hi, in the IMA documentation, there was a section on equ]"adrian > golding" ---10/17/2008 02:39:41 AM---hi, in the IMA documentation, there was > a section on equipping user space application to measure input files. This > would mean > > > From: > "adrian golding" <adr...@gm...> > To: > lin...@li... > Date: > 10/17/2008 02:39 AM > Subject: > [Linux-ima-user] extending IMA to measure files other than executables > ------------------------------ > > > > hi, in the IMA documentation, there was a section on equipping user space > application to measure input files. This would mean that i apache would have > to be modified with the supplied code in the documentation file in order to > measure a certain config file it loads. However, for another application X, > i would have to do the change to it as well. so i might have to modify code > in many places. > > if i want to modify IMA in a way that before it loads *any* file, it will > check : > a) if its something IMA now already measures > b) if that file is in a "to-be-measured" list (probably stored in the > harddrive - that list itself should also measured), > > if either (a) or (b) is satisfied, the file will be measured. > how feasible is this? How hard is it to implement this modification? > > by allowing the user to specify a list of files that he wants to measure > before they are loaded, what kinds of implications will there be? > > thank you - adrian > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > > > |