2

We'd like to keep track of user activity on one of our Centos7 machine. To do so, management decided to use script and scriptreplay to basically records user activity and replays it. I did some research on my side on how we should design it, but solutions relying on auditd are rejected here by management, and putting the script in the .profile of the user leads to some issues as explained below.

The expected behavior is as follow:

  1. When a user logs to the server via SSH, the script command spawns and starts logging user activity to a file.
  2. When the user is done on the server, he logs off (usually types exit or CTRLD).
  3. script process stops and close the file.

Now the issues:

  1. My researches showed me that script actually creates another shell. So if I put - let say - script script.log in the .bash_profile of every users (or in skel), it will issue a new shell for the user after login, and the user can easily abort the process and start typing commands in his usual SSH session. How can I force my script to actually kicks the user off when he exits the shell spawned by the script command ?

  2. The script output (ie. users' commands) should be stored in a private place where non-sudoers cannot do anything (no R/W/E permissions). How can we run scripts with elevated privilege on user login when the user is himself non-priviledged ?

Improve this question
3
  • 1
    For 1, we'd need to see the script and how it's called and for 2, you can not actually do it without giving the user elevated privileges, unless your script calls a logging daemon. Note that it would be interesting to know why they reject (auditd) that is apparently close to what they want.
    – Julie Pelletier
    Commented Aug 9, 2016 at 3:27
  • What JuliePelletier said, this is a use case auditd was designed for.
    – grochmal
    Commented Aug 9, 2016 at 3:31
  • The "script" is for now a simple entry in .bash_profile for every users: script -a script.log. I can push management to consider again auditd but the reason why it was rejected is obscure for us and it is unlikely to change.
    – nxr_jivra
    Commented Aug 9, 2016 at 3:34

1 Answer 1

Reset to default
2

As to the forcing a command, sshd has a ForceCommand option:

Forces the execution of the command specified by ForceCommand, ignoring any command supplied by the client and ~/.ssh/rc if present. The command is invoked by using the user's login shell with the -c option.
This applies to shell, command, or subsystem execution. It is most useful inside a Match block. The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable.

So from reading that, if you set ForceCommand to script, that should roughly do what you want.

As to keeping the audit trail safe, one solution in a multi-server system would be to learn from syslog and send the entries over the network to a different physical host. That pretty much prevents users from getting to logs after they've been generated. Failing anything else, you could probably rig something up to just send the logs to a different port on localhost, where a daemon collects and stores them. (Having tried the obvious, you can't script -f /dev/tcp/localhost/8888 since /dev/tcp/... would need to be handled by bash, so I guess you'd need to mkfifo yourself a communication path as in the manpage example for script -f)

Improve this answer
1
  • Thank you for this answer ! Seems to solve most of the problems !
    – nxr_jivra
    Commented Aug 10, 2016 at 2:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .