Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Have you looked into psacct, sar, and sa for command history? This has proven many times to be useful to me when tracing back user involvement, and user security snafus.
If you can find, at a certain date and time, the user who executed a command, the exact command that was run including arguments plus output or any "evidence" of said command (say an unprivileged user running 'fdisk /dev/sda; d; 1; n; p; w; q') using only psacct, sar, and sa please show.
An fair question, no, sa and psacct do not give the arguments passed. sa will give the user that ran the command, but is used for more summary information of commands, lastcomm is a more useful command, which I forgot to mention, it gives date, user, termination status etc. However you are correct that either will give you the arguments passed.
sa --print-users
-> this would give you all commands run, cpu time for each, and the user that ran them.
lastcomm --user $USERNAME
-> this would give you all commands run by a certain user, and the time at which they were run, sans the arguments passed.
lastcomm $COMMAND
-> this would give you all commands run that match $COMMAND
For catching arguments, snoopy is a good tool, used in conjunction with psacct commands, and sudo audit files/logging you can catch quite a bit of information for process/user command auditing
An fair question, no, sa and psacct do not give the arguments passed. sa will give the user that ran the command, but is used for more summary information of commands, lastcomm is a more useful command, which I forgot to mention, it gives date, user, termination status etc. However you are correct that either will give you the arguments passed. (..) For catching arguments, snoopy is a good tool, used in conjunction with psacct commands, and sudo audit files/logging you can catch quite a bit of information for process/user command auditing
If you reread this thread TTB you'll see that I already offered 'rootsh'. If you don't know about it I invite you to read the docs and take it for a spin. Corellating its logging with that of PAM plus Sudo plus Auditd definately gives you a way more detailed timeline and convincing audit trail.
I did skim through the thread, and I saw both sudosh, and rootsh offered up. I was merely pointing out psacct since it is a default install on many systems and yet few people use it :-). I haven't used auditd, I'll have to look into it.
Failing to find a suitable utility I wrote the following C program to log all commands on Fedora Core. The command and it's arguments are copied into a command buffer and is written to syslog, prefixed by the user-id and the process-id.
Code:
int execve(const char *filename, char *const argv[], char *const envp[])
{
int (*func)(const char *, char *const[], char *const[]);
char path[PATH_MAX + PATH_MAX];
FILE *fproc;
int loginuid;
char command[LINE_MAX + LINE_MAX];
int icommand, iarg;
size_t larg;
openlog("gwaudit", LOG_PID, LOG_AUTHPRIV);
sprintf(path, "/proc/%d/loginuid", getppid());
loginuid = -1;
if ((fproc = fopen(path, "r")) == NULL)
{
syslog(LOG_WARNING, "COULD NOT OPEN /proc FOR PROCESS %d", getppid());
}
else
{
if (fscanf(fproc, "%d", &loginuid) != 1)
{
syslog(LOG_WARNING, "COULD NOT READ loginuid FOR PROCESS %d", getppid());
loginuid = -1;
}
if (fclose(fproc) == EOF)
syslog(LOG_CRIT, "COULD NOT CLOSE FILE %s", path);
}
sprintf(command, "[%d:%d]", loginuid, getppid());
icommand = strlen(command);
for (iarg = 0; argv[iarg] != NULL; iarg++)
{
larg = strlen(argv[iarg]);
if ((icommand + 1 + larg) >= LINE_MAX)
{
syslog(LOG_WARNING, "COMMAND BUFFER TOO SMALL FOR ARG %s", argv[iarg]);
break;
}
command[icommand++] = ' ';
strcpy(command + icommand, argv[iarg]);
icommand += larg;
//should not happen
if (icommand >= LINE_MAX)
{
syslog(LOG_CRIT, "COMMAND BUFFER EXCEEDED INDEX=%d MAX=%d",
icommand, LINE_MAX);
break;
}
}
syslog(LOG_INFO, "%s", command);
*(void **) (&func) = dlsym(RTLD_NEXT, "execve");
return((*func)(filename, argv, envp));
}
Suppose you save this code as gwaudit.c it should be compiled as follows:
This will create a shared library gwaudit.so. It should be copied to a suitable location (and if you have SELinux enabled to a location that SELinux allows). I am using /usr/lib/gwaudit/gwaudit.so
The library should be tested in a shell in which you execute:
and execute some commands. On Fedora Core the commands are written to /var/log/secure and are shown as:
Aug 31 23:49:12 hostname gwaudit[2704]: [500:2660] su -
Aug 31 23:49:12 hostname gwaudit[2705]: [500:2704] /sbin/unix_chkpwd root nullok
Aug 31 23:49:14 hostname gwaudit[2706]: [500:2704] /sbin/unix_chkpwd root nullok
Aug 31 23:49:14 hostname gwaudit[2707]: [500:2704] /sbin/unix_chkpwd root chkexpiry
If the shared library works the path should be added to /etc/ld.so.preload. Should you ever need to replace the library, make sure you uncomment the path in /etc/ld.so.preload before you do it, otherwise you need your rescue-CD.
Regards,
Gijsbert
Last edited by gwiesenekker; 09-01-2009 at 01:45 AM.
Reason: Includes the user-id as well
No, nothing wrong, it's just that it is an echo of what's been said before and given certain purposes just not as configurable, versatile or trustworthy as the other options given before.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.