[clug] logging "rm" usage

[Burn Alting]

Can't all the alias solutions be circumvented by executing
/bin/rm? Or executing /bin/unlink? Also, what if I did
	/bin/unlink /tmp/logmame

I suppose it depends on how hostile the environment is.

Perhaps the best solution is a very simple C program which at worst uses
system(3C) to execute a 'hidden but executable' rm command and log the
execution somewhere where the user can't get at (setuid in a worst
case).

Burn Alting
burn at goldweb.com.au

On Thu, 2003-07-10 at 11:51, Steven Hanley wrote:
> On Thu, Jul 10, 2003 at 11:39:48AM +1000, Rousak, Boris wrote:
> > 
> > Thanks to all who replied to this issue. Having had a look at the c hooks
> > into the OS that are required i think this really is overkill for my
> > purposes (which are: simple auditing). Also this has to be easily portable
> > to Tru64 which the c code isn't (as i am a novice in c :) ). Opting for a
> > second option of simple script substitution and also command aliasing the
> > following did the job:
> > alias rm='echo $(date --iso-8601=seconds) $(whoami) >> /tmp/logname &&
> > /bin/rm $1'
> 
> hmm, that alias will only work in csh (variants) and some others, not in
> bash, bash does not handle arguments to aliases. Also the alias you have
> does not log the filename they removed, seems an interesting audit, you know
> who they are and when they removed something, but not what they removed.
> 
> If you want something that does not depend on the shell to work correctly I
> suggest a shell script called something like /usr/local/bin/log_rm and have
> the alias instead be
> 
> alias rm=/usr/local/bin/log_rm
> 
> This means the shell script can have arguments irrelevant of the calling
> shell, it can also be more complex later on if need be (such as logging the
> name of the deleted file).
> 
> 	See You
> 	    Steve