LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Bash History (http://www.linuxquestions.org/questions/linux-security-4/bash-history-104533/)

ukndoit 10-16-2003 12:29 AM

Bash History
 
I touched on this question in another thread, but not in the detail I want. that thread was about another topic, so I'm starting this thread.

this post:
postid=356002#post356002
talks about having the bash history only appending.

Is that ONLY for superuser?

Is it possible to make it where each user cannot delete their history, and make it where I can see their history, as superuser, so that I feel a little better about giving shell access to users?

I am nervous, but at the same time know that if we are going to compete, we must offer that as part of the service.

Thank you for any tips you have for me.

iainr 10-16-2003 04:29 AM

There are certainly apps that will do just this sort of thing, though I haven't played with any on Linux myself (the ones I've used have been on UNIX).

For a homegrown solution, try looking at the "script" command which records not only what the user types but also what the output was. Script launches a subshell so the trick will be to run it so that the user can't not run it and to prevent the user editing it.

The first is easy enough. Make sure the user can't edit their .bash_profile (or other startup file) and put a line at the end something like
script -a <log_file> ; exit

The second, stopping the user from editing the file, I would have to think about a bit. A quick-and-dirty solution might be to have a cron job running as root which copied the log file to another root-access-only file every minute. There might also be a clever way of using sudo or SUID to get the script command running as root but the shell as the user.

Iain.

unSpawn 10-16-2003 10:02 AM

LOL, no, that shouldn't apply to your situation if you're running a shell server...

Is it possible to make it where each user cannot delete their history, and make it where I can see their history, as superuser, so that I feel a little better about giving shell access to users?
First I'd like to warn you that if you're running a shell server then the scope of your "problem" is much wider than this. For instance you will have set up network and service ACL's, select and chown apps they are allowed to run to a different group and remove world perms from others, de-suid some apps, set restrictions on /home mount flags (dev, suid), sanitise your $ENV settings and on and on. This doesn't really depend on how much you trust or distrust those users, but more on how much of the risks you (won't) take for granted. In the end having a local account is a much more comfortable steppingstone for snooping around the system, cuz you're already in and admins trust local users more than they should.

As far as logging is concerned I'd suggest you patch your kernel with Grsecurity(.net)'s patches. Select as much of the options possible, but at least the stack and /proc protection features, "trusted path execution" (TPE), meaning they can't execute apps outside their $PATH (/lib/ld-linux.so trick won't work) and set the options for those users to have their exec's recorded. In addition you could restrict them to only have Bash for a shell and install Bash like this: http://www.rootshell.be/~unspawn/packaging/bash.html (this one's my rpm adaptation and repackaging, see original URI for more).

Make sure the user can't edit their .bash_profile (or other startup file) and put a line at the end something like script -a <log_file> ; exit
Shouldn't their shell just be "script -a ~/script.log"? Granted, running script gives much more detailed info, and there is a problem as well. More below.

The second, stopping the user from editing the file, I would have to think about a bit.
Not an optimal solution, and I would only recommend it in conjunction with a Grsecurity-protected kernel, even then anything that adds complexity to the system adds it's own pitfalls... If FS is ext2 or 3, as root you could try setting up a separate logdir:
mount /var -o remount,noexec,nosuid,nodev # Curb some user tricks
mkdir /var/tmp/scriptlog # Root-owned, /var 0700, /var/tmp 1777
chmod 1003 /var/tmp/scriptlog # Root-owned, world exec+writes no reads, or chgrp to main usergroup and chmod accordingly.
log=/var/tmp/scriptlog/${LOGNAME}.script
touch $log; chmod 0700 $log; chown ${LOGNAME}.${LOGNAME} $log
ln -sf ~/script.log $log; chattr +a $log
Since this will be a world-writable dir, you should do a quotacheck and edquota ${LOGNAME} so they're not capable of dossing the log partition.

Don't use your root account to snoop inside the dir: use an unprivileged account. Script logs control seq's as well and they may well fsck up your display. Don't use automatic logparsers to log data from this dir: a neat trick could be one semi-colon away. Also a simple "while [ $RANDOM ]; do logger hello; done" will have you grepping around for *REAL* logdata, so that way of dossing the log partition is still open unless you chmod logger accordingly.


In any case YMMV(VM)


[edit]
Stupid I forgot: you should log to a remote syslog server :-]
[/edit]


All times are GMT -5. The time now is 03:40 PM.