Looking at a shell ENV

[Jeff Machols]

Anyone know of a way to list the environment vairiables of a users active shell. I have a user that is screwing around and I want to see where he redirected his history (I think he does on the command line, after his profile runs). The only thing I can think of is to force a core a dump on the shell, but I would rather be a little quieter.

[Alan Casey]

As root you could su - tothe userid and look at the env there.

Or look at ~userid/.profile , .env , .login
Might find the answer there.

[Jeff Machols]

The problem is, he is setting these by hand after he logs in

[Alan Casey]

the only other thing I can suggest id to enable commands history for the user, and monitor them:

tail -f ~userid/.sh_history

You could then catch them out in the act.

[Alan Casey]

There may be a way to find if his history has been redirected fro his current shell.

With lsof or even fuser, you should be able to find all files open under this userid.
And locate the history

this may however be laborious.

[Steven Gillard_2]

How about the "set" command with no arguments. Its built into the shell, so see the sh-posix(1) man page for details.

Regards,
Steve

[Steven Gillard_2]

Ahh sorry, misread the question... only way I can think of to find their shell history file is with lsof.

Regards,
Steve

[harry d brown jr · Accepted solution]

Do this:

readonly HISTFILE
readonly HISTSIZE

live free or die
harry

[Jeff Machols]

Thanks Harry, put that in /etc/profile. At least all new logins will be able to be monitored

[harry d brown jr]

Steven makes a good point, download lsof (if you don't already have it) from:

http://hpux.asknet.de/hppd/hpux/Sysadmin/lsof-4.55/

It doesn't require a reboot, it's just a binary.

Then "lsof | grep history", providing they didn't rename their history file, but you can do a "lsof | grep ".

live free or die
harry

[Jeff Machols]

tried that, it looks like the file isn't always open (tried it on myself). It looks like ksh just appends to the file when needed but doesn't keep it open

[Steven Gillard_2]

In that case you could use tusc to find out what files the shell is opening. Eg:

# tusc -s 5

This will print out all the open system calls made by the process.

Another one of my personal favorites:

# tusc -s 3 -d 0

will print out all read system calls on stdin. So you can basically watch the users keystrokes as they are typed. Its always good to inform them of their spelling mistakes without having them read out what they have just typed over the phone :)

Cheers,
Steve

[Steven Sim Kok Leong]

Hi,

Three additional methods for tracing:

1) Enable auditing of user via sam. You will need to convert your OS to trusted before auditing can be performed.

2) Run account management via acctcom, runacct etc.

3) Use expect scripting to log all screen output of a user's login shell (I have seen it done on one system).

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Jeff Machols]

Steve,

I like that command, That will help a lot

THANKS

[Jeff Machols]

Steve,

it looks like the tusc command has a -e option to show env vars, but I can't seem to get it to work right. Either it's not what I think it is, or I am doing something wrong, any ideas?

[Bill Hassell]

Try sorting all the files in $HOME by timestamp:

ll -t ~user_name

The files at the top of the list were recently modified.

However, if this (ab)user is really hacing and wants no one looking over the shell commands, the HISTFILE variable may have been unset in which case the history file is no longer used.

The readonly suggestion probably makes a lot of sense, and you may have to append your company's security policy (you do have one don't you?) to state that "shell history files are required for system management and may not be bypassed".

[Jeff Machols]

Bill,

I am acutually running a find on all files that he owns. This user has been caught twice so I think he is definaltly hidding his actions, the tusc is working good, just a little cumbersome to try and read. There is nothing in the home directory, but I can see he is running commands.

[Steven Gillard_2]

Jeff,

You're right - it looks like it will display them only on an exec*() system call though. Try running

# tusc -f -p -e

against a shell, then run a command in the traced shell. After the forked process does an exec you will see the environment variables that are exported.

I guess that would mean the real answer to your question is to run:

# tusc -f -p -e -s 59

That will trace the execve() system calls made by child processes of the users shell and print out the environment variables. See /usr/include/sys/scall_define.h for all the system call numbers.

Cheers,
Steve

[Jeff Machols]

Thats exactly it Steve, now I have the proof I need to get rid of this %$*@er