Tuesday 6 September 2016

Spying on users with script

Giving superuser access to any user who is not a system administrator is a slippery slope. I've encountered a number of instances wherein people have removed important files, modified permissions of /etc to 777 recursively & even rebooted the system. Linux & Solaris provide a plethora of logging mechanisms to ensure that such actions are audited & logged. However, sometimes their output might be slightly difficult to interpret. 
I came up with a small hack to log all user activity once they log in till the time they log out using the script command.

So, here's the setup.

I appended the following line in .bash_profile file of user james:

script /var/log/session_logs/`whoami`.$(date +"%H:%M:%S\%d\%m\%Y").session.log

This command will log all terminal activity performed by user james to a file under /var/log/session_logs directory with userame & timestamp appended with the file name. The directory session_logs needs to be world writable. This is a bit of a security screen. I'll try to find a workaround to this situation in the future.

Here are the demo results:

When we logged in as james the script is started.

[root@devbox ~]# sudo su - james
Last login: Tue Sep  6 10:08:39 PDT 2016 on pts/4
Script started, file is /var/log/session_logs/james.10:11:40\06\09\2016.session.log

And when we log out the file is saved:

[root@devbox ~]# logout
[james@devbox ~]$ exit
Script done, file is /var/log/session_logs/james.10:11:40\06\09\2016.session.log
[james@devbox ~]$
[james@devbox ~]$ logout


The script files would be there in the destination directory:

[root@devbox ~]# cd /var/log/session_logs/
[root@devbox session_logs]# ls -l
total 4
-rw-rw-r-- 1 james root 1101 Sep  6 10:11 james.10:11:40\06\09\2016.session.log
-rw-rw-r-- 1 james root    0 Sep  6 10:13 james.10:13:49\06\09\2016.session.log


The only exception will be the case of a system reboot. In case james reboots the server, there will be a file created but it'll be empty. the file with size 0Kb is the case when james rebooted the server.

Not very accurate but still enough to get started with.

I hope it helps reduce some time spent troubleshooting catastrophes resulting from human error.

No comments:

Post a Comment

Using capture groups in grep in Linux

Introduction Let me start by saying that this article isn't about capture groups in grep per se. What we are going to do here with gr...