[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tiger-devel] [RFC] check_finddeleted
From: |
Ryan Bradetich |
Subject: |
Re: [Tiger-devel] [RFC] check_finddeleted |
Date: |
Wed, 07 Jan 2004 13:47:04 -0700 |
Hello Nicolas,
> 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)
I like the second method better. I should really go read the paper Javi
modeled the report after to make sure there is not a good reason to
seperate them out more ... but simplier is better :)
> 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?
group as in process id 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).
This is not completely portable either :( This fails on HP-UX.
$ ps -o cmd
ps: illegal option -- o
usage: ps [-edaflP] [-u ulist] [-g glist] [-p plist] [-t tlist] [-R
prmgroup]
I can get this to work by the following:
$ export UNIX95=1
$ ps -o args
but the output is truncated to a certain length. The only way I know of
to get the full command length is only available in HP-UX 11.11 where
they added a -x option to the ps command.
As different side note ... the command-line can be changed, so ps is not
the best way to get the process name. There are a several programs that
I know of that do this ... sshd, postgres, etc.
$ ps -e -o cmd | grep sshd
/usr/sbin/sshd
sshd: rbrad [priv]
sshd: address@hidden/4
grep sshd
$ ps -e -o cmd | grep postgres:
postgres: stats buffer process
postgres: stats collector process
postgres: rbrad vsm [local] idle
grep postgres:
Not sure if this matters ... but wanted let you know there might be
problems on other operating systems and with some programs.
> 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)
I think unit testing is important and have found most of the bugs by
testing tiger against HP's coporate security guidelines. I have been
trying to figure out a good way to incoporate a test suite also. :)
> 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.
oops ... I answered part of this question above. I will test out the
awk script on HP-UX later today and see if I can get it to work. Thanks
for the script :)
> Is a pure shell code preferable?
It make it easier to port and is more inline with the tiger philsophy,
but honestly doesn't matter to me.
> 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.
I would personally like to use the tiger.ignore as little as possible as
it could hide data :) if your proposal to update check_finddeleted
solves the problem then excellent :) That being said ... if we need the
filters, then lets add them to the tiger.default.
> Regarding Ryan's recent mails:
> Should I open a task in savannah for this? (and is a task the more
> appropriate section?)
It would be nice :) If we track projects we are working on more
publicly then maybe we won't duplicate effort :)
I think this sounds like task item to me.
> Is there a way to be notified for new tasks, bugs, or patches
> (any pointer on the savannah's tools?)
Not sure. I got notified but that is probabaly because it was me
submitting the bugs and the were assigned to me. I am still playing
around with the tools and trying to understand them as well :)
There is 1 bug in the tools you should be aware of (I sent a private
email to Javi with this info already) but the new task link does not
work. Use this link to add a new task:
https://savannah.nongnu.org/task/?group=tiger&func=additem
> Best Wishes,
You too!
- Ryan