[Tiger-devel] [RFC] check_finddeleted

[Nicolas François]

Happy New Year!

I worked on check_finddeleted some time ago, but stopped. A mail in
debian-security wake me up to announce this.

My goals were:
  1 - reduce its output
  2 - make it easier to ignore some report (help avoiding false negative)
 (3 - make it faster)
  4 - avoid some false positive

1 - reduce its output
  I think its output need to be reduced because there's some complaints
  (from me, on debian-security, debian bug #225112).
  
  There is already a way to ignore some reports, but it could generate
  false negative (see point 2).
  
  A server using a deleted files generates at least 2 reports. (apache
  with 2 child generate a dozen of reports).

2 - make it easier to ignore some reports (help avoiding false negative)
  server using a deleted file are reported (among the reports) this way:
    Server /usr/sbin/apache (pid 1187) is using deleted files

  my concern is that if I choose to automatically ignore this report,
  and if one time apache is using another deleted file, there will be a
  false negative.

  So, I think that there should always be a file name specified in the
  report.
  
3 - make it faster
  it's not actually really slow, but I would like to reduce the number
  of lsof call. It usually takes 2 or 4 seconds, but sometimes it took
  more than one minute (perhaps heavy load, lots of process?)

4 - avoid some false positive
  files or processes named *DEL* or *deleted* could lead to false
  positive.
  
  I did not checked what caused the false positive (e.g. apache, which I
  think is using safely /tmp/session_mm_apache0.sem). Is it possible to
  narrow the script to avoid them?
  (Javi's answer to debian bug #225112 could be a start)



I actually working on an awk script (attached).
It should be ready for the selection of suspected process, but there is
still work on the reporting part.
I choose to implement it with awk to get the full command name with
lsof. But the reporting part could be a completly separated function
wich receive a list of pid (reparsing the command name won't be time
consuming because there isn't a lot of reports). So I can do it in a more
pure shell fashion.



I have some questions on what should be its behaviour:

A - servers using a deleted file are more critical
  actually, there is a distinction between:
    *  processes using a deleted file and listenning
    *  processes using a deleted file and having one of its children
       listenning
    *  processes using a deleted file
  Should we keep those three classes? Should we add a distinction for
  processes using a deleted file and having its parent listenning, or
  more generally processes that have a listenning process in their
  group session.

  I would prefer having those two classes:
    * processes using a deleted file and being in the session of a
      listenning process.
    * processes using a deleted file.
  (processes using a deleted file and listenning could also be kept, my
   point is mostly on the "having its children listenning" and not other
   "familly members" restriction)

  Those classes would be reported as:
    * FAIL the process "name" (pid,user,group?) of the server "name" 
(pid,user,group?) is using a deleted file.
    * WARN the process "name" (pid,user,group?) is using a deleted file.
  Should we report the group?

B - Which name of process to report
  Actually, depending on the class, either the 8 letters truncated
  command name from lsof is reported, or the executable name with
  arguments (from ps -o cmd).

  Cons of "ps -o cmd":
    * can be very long
    * It can also be very different for scripts (a "test.py" python
      script will be displayed "python test.py").
  Pros:
    * probably safer (the executable path is included)
    * arguments can also be interesting for the security.

  In the first classe proposed above, a mix of both could be done (short
  command for the process name and executable name + args for the
  session leader name)

C - unit testing
  To test my awk script, I've done some small python scripts that use
  deleted file and listen.
  Do you think:
    * it could be interresting to keep them
    * it could be possible to add some tests for other scripts for unit
      testing (note that those scripts could be dangerous, and should be
      use only for testing, and should probably not be distributed. e.g.
      a script that would test if clear text passwords are detected and
      temporarily add a clear text password)

D - portability
  do you think there is portability issue with this awk script?
  apart from awk, I will use the same commands: lsof and probably ps.

  Is a pure shell code preferable?

E - is it resonnable to provide some tiger.ignore default for
    check_finddeleted
  I'm thinking of apache and gconf.
  I also get some rare reports for mutt or aptitude.


Regarding Ryan's recent mails:
  Should I open a task in savannah for this? (and is a task the more
  appropriate section?)
  Is there a way to be notified for new tasks, bugs, or patches
  (any pointer on the savannah's tools?)

Best Wishes,
-- 
Nekral

check_finddeleted
Description: Text document