9:28 p.m.
Steve,
This is a follow-up to the question I sent you earlier.
Thanks for the suggestions.
It does appear that the xdm login is auditing just fine, however the
audisp-prelude plugin appears to not send the events to the prelude
server.
I think this is the difference:
When sent by gdm it is this:
node=hugo type=USER_LOGIN msg=audit(10/29/2008 21:03:49.410:256209) : user pid=16890
uid=root auid=lenny subj=system_u:system_r:xdm_t:s0-s15:c0.c1023 msg='uid=lenny
exe=/usr/libexec/gdm-session-worker (hostname=, addr=?, terminal=/dev/tty7
res=success)'
When sent by xdm it is this:
node=v1 type=LOGIN msg=audit(10/29/2008 21:19:35.287:30749) : login pid=29371 uid=root old
auid=unset new auid=lenny old ses=4294967295 new ses=1646
Note that the types are different.
So, is USER_LOGIN (above) = AUDIT_USER_LOGIN 1112 (from libaudit.h) ?
If so, what is LOGIN? I guess I can go look at the code and find
out...but I guess that one isn't being grabbed inside the audisp-prelude
handle_event() routine.
If this is the case either the sending code could be made to match (I
guess pam isn't doing it the same way in each) or else the
audisp-prelude could be changed to send this one too?
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
10:27 p.m.
On Wed, 2008-10-29 at 21:28 -0500, LC Bruzenak wrote:
I think this is the difference:
When sent by gdm it is this:
node=hugo type=USER_LOGIN msg=audit(10/29/2008 21:03:49.410:256209) : user pid=16890
uid=root auid=lenny subj=system_u:system_r:xdm_t:s0-s15:c0.c1023 msg='uid=lenny
exe=/usr/libexec/gdm-session-worker (hostname=, addr=?, terminal=/dev/tty7
res=success)'
When sent by xdm it is this:
node=v1 type=LOGIN msg=audit(10/29/2008 21:19:35.287:30749) : login pid=29371 uid=root
old auid=unset new auid=lenny old ses=4294967295 new ses=1646
Note that the types are different.
So, is USER_LOGIN (above) = AUDIT_USER_LOGIN 1112 (from libaudit.h) ?
If so, what is LOGIN? I guess I can go look at the code and find
out...but I guess that one isn't being grabbed inside the audisp-prelude
handle_event() routine.
I found it:
/usr/include/linux/audit.h:#define AUDIT_LOGIN 1006
LCB
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
5:34 a.m.
On Wednesday 29 October 2008 22:28:18 LC Bruzenak wrote:
If so, what is LOGIN?
This is the record emitted by the kernel to say that the user's loginuid has
changed. This would mean that pam_loginuid was run. But the event is being
sent by the kernel, not pam.
I guess I can go look at the code and find out...but I guess that one
isn't
being grabbed inside the audisp-prelude handle_event() routine.
Because that is not an event of interest in prelide right now.
If this is the case either the sending code could be made to match
(I
guess pam isn't doing it the same way in each) or else the
audisp-prelude could be changed to send this one too?
Nope...somewhere the pam originating events are being eaten. You might strace
an xdm login and look for some sendto's followed immediately by recvfrom's to
the audit socket. If they are missing entirely, then xdm is not calling pam.
If they are there, we'd want to look at the return code to see if its having
an error. Is xdm running as root at the point pam is called? Are there
selinux rules? Are there dontaudit rules eating this?
-Steve
7:46 a.m.
On Thu, 2008-10-30 at 06:34 -0400, Steve Grubb wrote:
Nope...somewhere the pam originating events are being eaten. You might strace
an xdm login and look for some sendto's followed immediately by recvfrom's to
the audit socket. If they are missing entirely, then xdm is not calling pam.
If they are there, we'd want to look at the return code to see if its having
an error. Is xdm running as root at the point pam is called? Are there
selinux rules? Are there dontaudit rules eating this?
I bet you're right. I'll look for this.
I hate it when my own policy foils me...
:)
I appreciate the advice,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
9:29 a.m.
On Thu, 2008-10-30 at 07:46 -0500, LC Bruzenak wrote:
On Thu, 2008-10-30 at 06:34 -0400, Steve Grubb wrote:
>
> Nope...somewhere the pam originating events are being eaten. You might strace
> an xdm login and look for some sendto's followed immediately by recvfrom's
to
> the audit socket. If they are missing entirely, then xdm is not calling pam.
> If they are there, we'd want to look at the return code to see if its having
> an error. Is xdm running as root at the point pam is called? Are there
> selinux rules? Are there dontaudit rules eating this?
>
I removed the dontaudits with semodule -DB and the events are still not
there. So I don't think my policy is eating them.
Also no strace joy yet because it looks like xdm launches something else
which does the authentication.
So I went back to the gdm session which audits. I thought if I could see
the strace from that I'd know what to look for on the failing one. Here
is the USER_LOGIN event:
node=hugo type=USER_LOGIN msg=audit(10/30/2008 08:55:53.356:278784) : user pid=7417
uid=root auid=lenny subj=system_u:system_r:xdm_t:s0-s15:c0.c1023 msg='uid=lenny
exe=/usr/libexec/gdm-session-worker (hostname=, addr=?, terminal=/dev/tty7
res=success)'
So I attached strace to the running "gdm-session-worker" process but
that strace isn't particularly insightful (to me at least). How do I
know which one is the audit socket?
I ran a known audit test program and there I could deduce the audit
socket because I could see the text I was sending in the strace; e.g.:
sendto(4, "\274\0\0\0a\4\5\0\1\0\0\0\0\0\0\0real-pri=2, real"..., 188, 0,
{sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 188
But looking earlier in the strace doesn't give me much clue as to FD=4
being the audit socket.
Any suggestions are welcome; thanks again for the help!
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
1:07 p.m.
On Thursday 30 October 2008 10:29:12 LC Bruzenak wrote:
So I went back to the gdm session which audits. I thought if I could
see
the strace from that I'd know what to look for on the failing one. Here
is the USER_LOGIN event:
node=hugo type=USER_LOGIN msg=audit(10/30/2008 08:55:53.356:278784) : user
pid=7417 uid=root auid=lenny subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
msg='uid=lenny exe=/usr/libexec/gdm-session-worker (hostname=, addr=?,
terminal=/dev/tty7 res=success)'
OK, so i just remembered that I patched gdm, login, and sshd specifically to
send the USER_LOGIN event. I did not patch xdm or kdm or shadow-utils login.
So, I think it will need to be patched to send this one event.
-Steve
5897
days inactive
5897
days old
linux-audit@lists.linux-audit.osci.io
5 comments
2 participants
participants (2)
-
LC Bruzenak -
Steve Grubb