Sponsored Content
Full Discussion: .bash_history
Top Forums UNIX for Advanced & Expert Users .bash_history Post 28337 by Neo on Tuesday 17th of September 2002 10:09:27 AM
Old 09-17-2002
The way to proceed is to develop (or use exisiting) a wrapper program around the user login that logs all standard-in from keyboard, and logs this information securely so the user cannot modify.

I wrote a C program called 'keylog.c' that does just this for an HP-UX platfrom that did some very critical transactions and had users logging in from all over the world to debug real-time and near-real time errors.

The program basically wrapped around the user shell and logged all the keystrokes, with timestamps a the beginning of the login session and one at the end, of the user. The process could be killed by the user, but if a use attempted to kill the logging program, the program trapped the kill signal and would kill all child processes. If you can imagine this, this means that the user killed or attempted to kill the logging program, the user would be immedately logged out because his shell would die immediately.

BTW: None of this is performed with HISTORY and other shell functions. These are not reliable and were not designed for security, tracing nor auditing.

Worked great and the platform received insurance certification from LLoyds of London, which meant that enough security controls were in place to reasonably insure (not perfect, but good enough to insure combined with other controls).

I disagree with an earlier comment that 'if you don't trust users, don't let them login'..... they are simply too many production servers that require tracing and logging. Trust is relative and most mistakes that cost companies the biggest money are not from malicious activities, they come from well intended users who make honest mistakes. Those user makes must be traceable (to the user) and auditable in many applications.


(BTW: None of what I describe above is accomplished with shell history files like .sh_history, etc. Those files are not designed for real security applications.)
 

8 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Change .bash_history to another one

we need the help to change .bash_histroy file in root ,(i.e) we want to save the histroy for .temp.txt for permenently. how to do?? Help us (1 Reply)
Discussion started by: thakshina
1 Replies

2. UNIX for Advanced & Expert Users

.bash_history

During the course of the session before I logout I see some of the commands listed from my previous session but not from my current session and after I logout and log back in I see the commands which I ran before logging out. Does the .bash_history stay in the buffer or someplace else then? ... (2 Replies)
Discussion started by: jacki
2 Replies

3. Shell Programming and Scripting

.bash_history

Dear All, I am creating users on our servers. the .bash_history supposed to store all the commands entered by the user. My question is, how can I prevent the user himself from editing or viewing this file? I have tried chaning the owner of the .bash_history to be the root user but... (5 Replies)
Discussion started by: charbel.n.s
5 Replies

4. UNIX for Advanced & Expert Users

.bash_history modification

Hi Experts, I know my question would be strange but i need to understand how the .bash_history file is logging user actions (the mechanism) and if possible modify it to include also the date/time of every action done by the user. Sample file: # more .bash_history ssh <IP address> -l axadmin... (3 Replies)
Discussion started by: Dendany83
3 Replies

5. UNIX for Dummies Questions & Answers

how to store time in .bash_history file

Hi - user commands are written in . bash_history of that user when he logs out. my bash_history file shows. not sure what that number means #1329618972 ls -la #1329618978 ls #1329618980 ls -la my bash_profile looks like this PATH=$PATH:$HOME/bin export PATH export... (3 Replies)
Discussion started by: oraclermanpt
3 Replies

6. UNIX for Advanced & Expert Users

How to recover .bash_history?

rm -rf .bash_history some one ran rm -rf .bash_history on my Linux server(SUSE),I can see this command being run in current history, but I want the OLD history as well,can I recover the old history back. (9 Replies)
Discussion started by: Ankit Bansal
9 Replies

7. Shell Programming and Scripting

Display .bash_history with timestamp using script

Hi would like to ask if there is anyway to display .bash_history with timestamp using shell script? i know that you should use history command with HISTTIMEFORMAT="%d/%m/%y %T " to display it in terminal but it does not work when i use it on shell script. It seem that you can't run history... (1 Reply)
Discussion started by: pikamon
1 Replies

8. UNIX for Beginners Questions & Answers

How to get the "history" command to show all that is in the .bash_history file?

I am using the bash shell. When I view my recent command history using the "history" command from the prompt, it only shows me the commands starting at #928. The commands I need are earlier than that, but I can't figure out how to make the other 927 display. They are in my .bash_history... (1 Reply)
Discussion started by: Twinklefingers
1 Replies
PAM_SYSTEMD(8)							    pam_systemd 						    PAM_SYSTEMD(8)

NAME
pam_systemd - Register user sessions in the systemd control group hierarchy SYNOPSIS
pam_systemd.so DESCRIPTION
pam_systemd registers user sessions in the systemd control group hierarchy. On login, this module ensures the following: 1. If it does not exist yet, the user runtime directory /run/user/$USER is created and its ownership changed to the user that is logging in. 2. The $XDG_SESSION_ID environment variable is initialized. If auditing is available and pam_loginuid.so run before this module (which is highly recommended), the variable is initialized from the auditing session id (/proc/self/sessionid). Otherwise an independent session counter is used. 3. A new control group /user/$USER/$XDG_SESSION_ID is created and the login process moved into it. On logout, this module ensures the following: 1. If $XDG_SESSION_ID is set and kill-session-processes=1 specified, all remaining processes in the /user/$USER/$XDG_SESSION_ID control group are killed and the control group is removed. 2. If last subgroup of the /user/$USER control group was removed the $XDG_RUNTIME_DIR directory and all its contents are removed, too. If the system was not booted up with systemd as init system, this module does nothing and immediately returns PAM_SUCCESS. OPTIONS
The following options are understood: kill-session-processes= Takes a boolean argument. If true, all processes created by the user during his session and from his session will be terminated when he logs out from his session. kill-only-users= Takes a comma separated list of user names or numeric user ids as argument. If this option is used the effect of the kill-session-processes= options will apply only to the listed users. If this option is not used the option applies to all local users. Note that kill-exclude-users= takes precedence over this list and is hence subtracted from the list specified here. kill-exclude-users= Takes a comma separated list of user names or numeric user ids as argument. Users listed in this argument will not be subject to the effect of kill-session-processes=. Note that that this option takes precedence over kill-only-users=, and hence whatever is listed for kill-exclude-users= is guaranteed to never be killed by this PAM module, independent of any other configuration setting. controllers= Takes a comma separated list of control group controllers in which hierarchies a user/session control group will be created by default for each user logging in, in addition to the control group in the named 'name=systemd' hierarchy. If omitted, defaults to an empty list. reset-controllers= Takes a comma separated list of control group controllers in which hierarchies the logged in processes will be reset to the root control group. debug= Takes a boolean argument. If yes, the module will log debugging information as it operates. Note that setting kill-session-processes=1 will break tools like screen(1). Note that kill-session-processes=1 is a stricter version of KillUserProcesses=1 which may be configured system-wide in systemd- logind.conf(5). The former kills processes of a session as soon as it ends, the latter kills processes as soon as the last session of the user ends. If the options are omitted they default to kill-session-processes=0, kill-only-users=, kill-exclude-users=, controllers=, reset-controllers=, debug=no. MODULE TYPES PROVIDED
Only session is provided. ENVIRONMENT
The following environment variables are set for the processes of the user's session: $XDG_SESSION_ID A session identifier, suitable to be used in file names. The string itself should be considered opaque, although often it is just the audit session ID as reported by /proc/self/sessionid. Each ID will be assigned only once during machine uptime. It may hence be used to uniquely label files or other resources of this session. $XDG_RUNTIME_DIR Path to a user-private user-writable directory that is bound to the user login time on the machine. It is automatically created the first time a user logs in and removed on his final logout. If a user logs in twice at the same time, both sessions will see the same $XDG_RUNTIME_DIR and the same contents. If a user logs in once, then logs out again, and logs in again, the directory contents will have been lost in between, but applications should not rely on this behaviour and must be able to deal with stale files. To store session-private data in this directory the user should include the value of $XDG_SESSION_ID in the filename. This directory shall be used for runtime file system objects such as AF_UNIX sockets, FIFOs, PID files and similar. It is guaranteed that this directory is local and offers the greatest possible file system feature set the operating system provides. EXAMPLE
#%PAM-1.0 auth required pam_unix.so auth required pam_nologin.so account required pam_unix.so password required pam_unix.so session required pam_unix.so session required pam_loginuid.so session required pam_systemd.so kill-session-processes=1 SEE ALSO
pam.conf(5), pam.d(5), pam(8), pam_loginuid(8), systemd-logind.conf(5), systemd(1) AUTHOR
Lennart Poettering <lennart@poettering.net> Developer systemd 10/07/2013 PAM_SYSTEMD(8)
All times are GMT -4. The time now is 05:22 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy