Unix command-line _arguement_ signatures

Richard A Childers (pascal@netcom.com)
Mon, 12 Sep 1994 14:46:55 -0700 

Has anyone done any research on using command-line arguements as part of
the user profiling used for intrusion detection ?

This may be a naive question ... but many of the discussions I have seen
seem to center on which _commands_ are used, and constructing a profile
based upon _this_ data alone.

I have seen no discussions which specifically mention the command line
_arguements_. This, I extrapolate, is because few existing security log
mechanisms collect this data ... and this, I extrapolate, might be because
the command line buffer data is rewriteable by the command, once it starts
to run ( at least, in a Unix environment ), or perhaps simply because it
increases the amount of data needing to be logged, by an order of magnitude.

				-=8=-

However, I think this problem of it not being collected can be gotten around
by writing "wrappers" which reside in /usr/bin, log the command line data,
and then pass the arguements to the real, otherwise-inaccessible command.

This data could then be parsed for directory names and command-line flags,
which would map directly to user profiles in a fairly direct fashion.

I think that command arguements would be particularly useful, insofar as
almost no two people use 'ls' or 'ps', for instance, in the same way, or
with the flags in the same order. This sort of thing is pretty distinctive
when using a command that has, maybe twenty or thirty arguements. The way
a person does I/O redirection and lines up their pipes are also distinctive,
for instance, some people are obsessive about whitespace between their
I/O redirects and their file names.

				-=8=-

Thinking about where such an added value would best reside ( for wrappers
are a pain and perhaps an added overhead that no one wants ), I think it
would nest into a Unix "shell" very nicely. After all, that's where the
command-line parsing is done ... why do it twice ?

This would provide a nice clean split of services, such that those that did
not want or need such would have the option of using a less formidable shell.
It would allow such security services - which are, after all, user-driven
as well as user-oriented - to be selected on a user-specific basis.

This would also give administration an 'out' when break-ins occurred. 'We
set her up with the spiffy new secsh in her /etc/passwd entry, but she used
the 'chsh' command to change it, and, per our Regulation Z9ab2-x, this makes
her liable for protecting her account and divorces us from the process ..."

( One problem I haven't thought of a solution for, is where to keep the
  data that IDs the user. It has to be inaccessible to the user, so such
  a shell would need the support and assistance of system administration.
  It's possible it could do the security-related parsing on the fly, and
  not have to keep a big log of data ... but the question of where to keep
  the profile it reads upon startup, remains unsolved. )

Comments ? Suggestions ? Volunteers ?		(-;


-- richard

                 Law : The science of assigning responsibility.
              Politics : The art of _distributing_ responsibility.

   richard childers        san francisco, california        pascal@netcom.com