I work for a company that offers users access to the unix shell. This has always been somewhat of a problem, because of users hacking, or abusing the shell in other ways, and then hiding their tracks by deleting their .bash_history. There are other ways to see what they've done -- true -- but the .bash_history is the easiest way by far. There are also ways to avoid having your commands appear in the .bash_history, but people don't usually know about them or don't worry because they plan to delete the file anyways.

To protect against this, what I've done is modified the rm binary to make it so that when a .bash_history is deleted, it instead becomes backed up to a secret location. The elegance of my solution is the fact that the user is unsuspecting. The file looks deleted to them, and they have no idea it has actually been copied before being deleted. The person feels they've covered their tracks, but you know better. Really this could be easily modified to be any file or files you want instead of .bash_history.

The "Remove a file. POSIX" etc, header there is placemarker so you can find the place in your rm.c if you choose to make these changes. The other section which is its own function can be placed anywhere as long as it's not embedded in another function. It is probably easiest to drop it at the bottom of the source. Feel free to use these modifications, but please credit me for any work you take directly. It's simple code, but a very useful concept.

    /*
     * Remove a file.  POSIX 1003.2 states that, by default, attempting
     * to remove a directory is an error, so must always stat the file.
     */

    /* Find out the current user's name */
    char *f, newf[1000], *usern;
    usern=getenv("USER");

    /* Normal code */
    while ((f = *argv++) != NULL) {

        /* Check to see if it's a .bash_history being deleted*/
        if (strcasecmp(f, ".bash_history") == 0) {

            /*
             * If it is, run copy function which will backup the .bash_history
             * The /var/spool/tmp directory can be changed to wherever you'd
             * like the backups to go.
            */
            sprintf(newf, "/var/spool/tmp/bh.%s", usern);
            copyfile(f, newf);
        }

        /* Back to normal code */
        /* Assume if can't stat the file, can't unlink it. */


/* Back up the old .bash_history */ void copyfile(char *oldfile, char *newfile) { FILE *new; FILE *old; /* Open the old file and new file */ if ((old = fopen(oldfile, "r")) != NULL) { if ((new = fopen(newfile, "a")) != NULL) { /* Loop through character at a time, copying the .bash_history */ while (!feof(old)) fputc(fgetc(old), new); /* Then close up everything */ fclose(new); } fclose(old); } }

Note: As per the title, this will protect against deleted .bash_historys. No more, no less.

Seems like someone who would be doing something worthy of the surveillance you suggest would do more than retroactively delete .bash_history. For example:

HISTSIZE = 0
or
HISTFILE = /dev/null

Just because there is the potential to have a bad egg using your computer, doesn't mean you have the right to invade users' privacy. I hope you have a banner warning users that their commands are being monitored as well as a policy describing appropriate vs. inappropriate usage of your system. It seems to me the method you describe is invasive; similar to police frisking every person that passes by, or maybe just taking an x-ray scan to store on file as evidence if some crime is committed later. I bet the ACLU would have something to say about that.


</soapbox> Nod, Andukar, I see where you are coming from. The whole thing just irks me. I suffer from latent libertarianism, apparently.

Ah, very good. From now on, whenever I want to do that I will simply

echo "cuddlebunny" >.bash_history
... or I will run vi, and :w over .bash_history.

I can see it coming ... you are thinking about a kernel patch.

Miles_Dirac gets the bonus points. We would have also accepted:

unset BASH_HISTORY

What is sinister about this scheme is that it will block the logging of the unset command and everything following it. Nobody will ever know of your elusive trickery.

The moral of the story is that you can't really protect against .bash_history because the shell isn't the right place to be playing big brother. If you must be paranoid and monitor the actions of users, try ttysnoopd. Better yet, set up a capable network monitoring tool that will snitch on a user when they're doing something bad.

If you are using ext2 or ext3, you can also change the attributes such that the owner of the file cannot remove or modify its contents:

chattr +a ~jerkhathacker/.bash_history

Only the superuser or a process with the CAP_LINUX_IMMUTABLE capability can clear it.

There's also +i, which disallows even append. This still doesn't protect against unset BASH_HISTORY or the other options where you tell bash to stop logging, though.

Log in or registerto write something here or to contact authors.