3

We have implemented a workaround to save command history in a new file for each user session for audit purpose. So each session file is identified by the start time and the username.

The problem: The session user is the file owner, so he is able to modify or even delete it.

Is there a way, once the file is filled, to prevent any change on it ? It's like write-once and it's locked.

2
2

What you are suggesting is nigh impossible to do properly with standard tools.

As you noticed, saving the command history is usual will not work, since the file will be owned by the user, and they can can delete, clear or edit the file at will. Even if we could work around this, perhaps by making the command history file a pipe read by some trusted process, there's nothing to stop the user from just turning off the history file or pointing it somewhere else.

We could create a new shell with mandatory command logging to prevent that (with the logs sent to another process via a pipe, socket or syslog), but the user could still simply start a normal shell, or a Perl or Python interpreter among other things, to work around the logging. Logging what the subprocesses did, would require wrapping the whole session in script or similar to log everything the user sees. Even then there is the possibility of just downloading code and running it, without printing it on the terminal. Preventing the user from running arbitrary programs would do it, but it would also prevent doing most useful things. Preventing running shells or Perl scripts would also prevent many common tools from working.

This result isn't surprising, considering that the shell and other utilities are meant as a tool for the user, not against them.

Perhaps you could arrange the user's session to be wrapped in strace or similar to see every interaction their processes had with the system, but reading the strace log from a longish session would not be much fun.

Also, I would think your users would object to this level of monitoring, I know I would.

3
  • I appreciate you taking the time to write these suggestions, I will consider the "trusted process" one.
    – user619005
    Jul 19 '16 at 15:29
  • The command history file could be made append-only and placed in a directory owned by root. However, that would not help with auditing since users could switch off history logging or run another shell. Jul 19 '16 at 23:33
  • That piping to a root-owned process idea could be combined with an /etc/bash.bash_logout script (which could, e.g. save command history to a file, or into an sql db with at least uid, euid, date, time, and history text fields). See my answer to unix.stackexchange.com/questions/49229/… for an example. It's far from perfect, but it's good enough for casual use.
    – cas
    Jul 20 '16 at 3:57
0

It's difficult to give a good answer without knowing more about your setup, but it sounds like a way to achieve some of your goals, assuming you use a file system that supports it, such as ext3, would be to mark the log file "append-only", using chattr +a <file>.

Setting or unsetting the attribute requires special privileges, and then the file can only be appended to. This would not prevent your users from appending arbitrary data to the file, but it would prevent them from removing any data that is already there.

2
  • Like you said, this command require special privileges. How to apply chattr on a new file without root intervention ?
    – user619005
    Jul 19 '16 at 14:29
  • @user619005 You can't. But it's useless anyway: users could easily bypass the command history file (e.g. by turning history off or using another shell). Jul 19 '16 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.