LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices



Reply
 
Search this Thread
Old 10-16-2003, 12:29 AM   #1
ukndoit
LQ Newbie
 
Registered: Sep 2003
Posts: 3

Rep: Reputation: 0
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.
 
Old 10-16-2003, 04:29 AM   #2
iainr
Member
 
Registered: Nov 2002
Location: England
Distribution: Ubuntu 9.04
Posts: 631

Rep: Reputation: 30
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.
 
Old 10-16-2003, 10:02 AM   #3
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,700
Blog Entries: 54

Rep: Reputation: 2964Reputation: 2964Reputation: 2964Reputation: 2964Reputation: 2964Reputation: 2964Reputation: 2964Reputation: 2964Reputation: 2964Reputation: 2964Reputation: 2964
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]

Last edited by unSpawn; 10-16-2003 at 10:08 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Bash history file jinksys Linux - Software 2 07-30-2005 04:58 PM
NOT escaping bash history ivanatora Linux - General 3 06-07-2005 02:17 PM
history not working in bash subu_s AIX 2 12-29-2004 01:49 PM
bash history slowly Linux - General 2 11-12-2004 12:35 PM
F8 for command history in bash titanandrews Linux - General 7 10-15-2004 04:25 PM


All times are GMT -5. The time now is 02:25 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration