2:31 p.m.
Classification: UNCLASSIFIED
Caveats: NONE
Hello everyone,
Newbie to the list. I am in position of writing technical
implimentation guidance for DISA and I am looking for a method to audit
logins/logouts. I have not been able to come up with a syscall that
would cover this. Any help would be appreciated.
Jason Mackanick, CISSP
DISA FSO Supports & Standards Section
Technical Support Team
Classification: UNCLASSIFIED
Caveats: NONE
3:13 p.m.
On Wednesday 28 February 2007 15:31, Mackanick, Jason W CTR DISA GIG-OP wrote:
I am in position of writing technical implimentation guidance for
DISA and I
am looking for a method to audit logins/logouts.
We've patched login, gdm, and openssh to send a USER_LOGIN message to denote
this event.
time->Wed Feb 28 08:12:01 2007
type=USER_LOGIN msg=audit(1172668321.325:113): user pid=2424 uid=0 auid=525
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=525:
exe="/usr/sbin/gdm-binary" (hostname=discovery, addr=192.168.1.2, terminal=:0
res=success)'
I have not been able to come up with a syscall that would cover this.
Any
help would be appreciated.
Its actually a whole series of events that allows a login. Thesequence is:
LOGIN, USER_AUTH, USER_START, USER_ACCT, USER_START, CRED_REFR or CRED_ACQ ,
and then USER_LOGIN. Cron and some other daemons that are pamified can create
most of these events as they run. This is why we send a specific event from
the app. Aureport looks for USER_LOGIN messages for its login accounting.
[root]# aureport --start today
Summary Report
======================
Range of time in logs: 10/29/2006 13:11:33.731 - 02/28/2007 16:05:52.479
Selected time for report: 02/28/2007 00:00:01 - 02/28/2007 16:05:52.479
Number of changes in configuration: 0
Number of changes to accounts, groups, or roles: 0
Number of logins: 1
Number of failed logins: 0
Number of authentications: 2
Number of failed authentications: 1
Number of users: 1
Number of terminals: 4
Number of host names: 2
Number of executables: 2
Number of files: 1
Number of AVC denials: 0
Number of MAC events: 0
Number of failed syscalls: 0
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of process IDs: 4
Number of events: 13
If you want more detail, run the login report:
[root]# aureport --start today --login -i
Login Report
============================================
# date time auid host term exe success event
============================================
1. 02/28/2007 16:05:38 steve nat.redhat.com /dev/pts/0 /usr/sbin/sshd yes 81
Hope this helps.
-Steve
3:18 p.m.
On Wed, 28 Feb 2007 15:31:41 EST, "Mackanick, Jason W CTR DISA GIG-OP" said:
Newbie to the list. I am in position of writing technical
implimentation guidance for DISA and I am looking for a method to audit
logins/logouts. I have not been able to come up with a syscall that
would cover this. Any help would be appreciated.
That's because "login" isn't a single syscall, and a lot of things
happen
during a login - many files get read, programs get run, and so on. That's
why things like gdm, getty, and ssh are modified to cut a non-syscall
audit record when a user logs in.
4:48 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
So does that mean this call audit would not work:
- -a exit,possible -w /bin/login -F success=0 -F success!=0
What would be an entry to trap users successfully logging in?
Paul Whitney
Paul.whitney(a)mac.com
On 2/28/07 4:18 PM, "Valdis.Kletnieks(a)vt.edu" <Valdis.Kletnieks(a)vt.edu>
wrote:
* PGP Signed by an unverified key: 02/28/07 at 16:18:26
On Wed, 28 Feb 2007 15:31:41 EST, "Mackanick, Jason W CTR DISA GIG-OP"
said:
> Newbie to the list. I am in position of writing technical
> implimentation guidance for DISA and I am looking for a method to audit
> logins/logouts. I have not been able to come up with a syscall that
> would cover this. Any help would be appreciated.
That's because "login" isn't a single syscall, and a lot of things
happen
during a login - many files get read, programs get run, and so on.
That's why things like gdm, getty, and ssh are modified to cut a
non-syscall
audit record when a user logs in.
* Valdis Kletnieks <valdis.kletnieks(a)vt.edu>
* 0xB4D3D7B0 - Unverified (L)
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.6 (Build 6060)
iQEVAwUBReYGxbdVg+viRqgEAQhLOQgAg5/QLzVIl1raeQdZ7l9nv++wma+fVre9
eo4WifDvQIA07rttrpXkJhYGbDYHKOoWZQzgMfYW77pNJjBgmyopFUmqGMlLoNym
0rF9tT6rdexpgEheqm0yNjL6S2B2iGU3rg+fY3KiLOEy42b0bpfWbExTE21PEB7l
1MS/pZSnbmNSEe0Jg4vH+8iNdMKBdIfr8qWCr4pSFoWr9eOcI0vaCHUWEdmbtynu
wpWlFwCEJ46Mm/YdPC8FRCHzOuLGHjp6GyoFVcc6tHWZ982KSR0l9a9+Q5EBE8vD
nZcfpKB0Xmcp3mtoN/V4ZryCHpuGYgwUzVimcHcqRI9stqecfkjMMw==
=js9E
-----END PGP SIGNATURE-----
4:54 p.m.
On Wednesday 28 February 2007 17:48, Paul Whitney wrote:
So does that mean this call audit would not work:
-a exit,possible -w /bin/login -F success=0 -F success!=0
This would not audit anything for 3 reasons. "possible" tells it to collect
the information in case its needed later. The -F options form an "and"
condition. Both cannot be true at the same time. And "-w" is watches
while "-a" is syscall auditing...you cannot mix the two.
You might try:
-w /bin/login -p x
But that would get you the fact that the file was executed but probably not
the results of execution. (It probably should).
What would be an entry to trap users successfully logging in?
We've patched the source code to entry points to send specific messages saying
the intent of the pam session.
-Steve
7:41 a.m.
Classification: UNCLASSIFIED
Caveats: NONE
I am running the standard auditd delivered with rhel4. What is the
latest set of rpm's that I should have to see the login functionality?
I am on a non-internet-connected network that I can not use up2date for
packages.
Jason Mackanick, CISSP
DISA FSO Supports & Standards Section
Technical Support Team
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Wednesday, February 28, 2007 5:54 PM
To: linux-audit(a)redhat.com
Cc: Paul Whitney; Valdis.Kletnieks(a)vt.edu; Mackanick, Jason W CTR DISA
GIG-OP
Subject: Re: Login/Logouts (UNCLASSIFIED)
On Wednesday 28 February 2007 17:48, Paul Whitney wrote:
So does that mean this call audit would not work:
-a exit,possible -w /bin/login -F success=0 -F success!=0
This would not audit anything for 3 reasons. "possible" tells it to
collect the information in case its needed later. The -F options form an
"and"
condition. Both cannot be true at the same time. And "-w" is watches
while "-a" is syscall auditing...you cannot mix the two.
You might try:
-w /bin/login -p x
But that would get you the fact that the file was executed but probably
not the results of execution. (It probably should).
What would be an entry to trap users successfully logging in?
We've patched the source code to entry points to send specific messages
saying the intent of the pam session.
-Steve
Classification: UNCLASSIFIED
Caveats: NONE
8:05 a.m.
On Thursday 01 March 2007 08:41, Mackanick, Jason W CTR DISA GIG-OP wrote:
I am running the standard auditd delivered with rhel4. What is the
latest set of rpm's that I should have to see the login functionality?
It was delivered in the RHEL4U3 set (audit, pam, login, openssh, gdm). I would
recommend using RHELU4 audit package (audit-1.0.14) and the latest errata
RHEL4 kernel (released this week) as well since it has an important audit
fix.
-Steve
8:21 a.m.
Classification: UNCLASSIFIED
Caveats: NONE
Everyone, Thanks for the help.
Jason Mackanick, CISSP
DISA FSO Supports & Standards Section
Technical Support Team
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Thursday, March 01, 2007 9:05 AM
To: Mackanick, Jason W CTR DISA GIG-OP
Cc: linux-audit(a)redhat.com
Subject: Re: Login/Logouts (UNCLASSIFIED)
On Thursday 01 March 2007 08:41, Mackanick, Jason W CTR DISA GIG-OP wrote:
I am running the standard auditd delivered with rhel4. What is the
latest set of rpm's that I should have to see the login functionality?
It was delivered in the RHEL4U3 set (audit, pam, login, openssh, gdm). I would recommend
using RHELU4 audit package (audit-1.0.14) and the latest errata
RHEL4 kernel (released this week) as well since it has an important audit fix.
-Steve
Classification: UNCLASSIFIED
Caveats: NONE
6506
days inactive
6507
days old
linux-audit@lists.linux-audit.osci.io
7 comments
4 participants
participants (4)
-
Mackanick, Jason W CTR DISA GIG-OP -
Paul Whitney -
Steve Grubb -
Valdis.Kletnieks＠vt.edu