RE: (no subject)
Aha - I see that there is an audit event for the auid change. Thats good enough for me - thanks I still have a couple of questions A) sometimes as root I echo to /proc/self/loginuid and it is ignored. Why? There is no error message B) always if I echo to /proc... as non root it is ignored (as it should be) but no message is generated; shouldn't it say EPERM? C) I put pam_loginuid in my gdm pam config but my xterm windows still have -1 in loginuid (I have rebooted) -Original Message- From: Steve Grubb [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 4:32 PM To: linux-audit@redhat.com Cc: paul moore Subject: Re: (no subject) On Friday 20 April 2007 18:13:17 paul moore wrote: > My understanding is that the auid/loginid process property is to allow > the audit system to *really* know who did things In particular it > seems to be for tracking who did things when they run su or sudo Yep. > But it seems to be trivial to spoof it > > login as: paul > [EMAIL PROTECTED]'s password: > Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101 > [EMAIL PROTECTED] ~]$ sudo bash > [EMAIL PROTECTED] ~]# cat /proc/self/loginuid > [EMAIL PROTECTED] ~]# echo 600 > /proc/self/loginuid But you will generate an audit message right here saying that you changed the loginuid. While its not protection, it doesn't quietly let that occur. > I was 556 at login, after sudo i am still 556 but then as root I can > now change it to 600 and the audit log for my actions has auid=600 in > it doesnt that undermine the whole point of the login id? There should still be a trail showing that you changed it. > Surely once it has been set it should not be possible to change it again. I think there are 1 or 2 daemons that count on that. > I see a debate in the thread "proc_loginuid_write() checks wrong > capability" about who should be able to do this but it misses the > point. It should only be writtable if its -1 at the moment. Otherwise > it must be unconditionally rejected. Except in the case where daemons are changing loginuid temporarily to record the fact that its doing something on behalf of a user. For example, I think postfix may do this when delivering email and reading the dot files. > The argument for it being like it is is that root is all powerfull so > they should be allowed to do anything. But the beauty of auid is that > it lets me see who the root sudoer really is. But there is a problem here...if you strip the CAP_AUDIT_CONTROL bit and and admin does a restart of sshd, sshd will not be able to set it either. If you only allow setting auid if its non-zero, how do you restart a service like sshd since it will inherit the loginuid? The only option is to reboot the machine, so forget about rpm upgrades. I really think the answer is to protect this with SE Linux policy...but there is a problem. I think that by setting loginuid by the proc filesystem we won't be able to have a SE Linux type that is distinct for loginuid without changing things in the kernel. Then you also have to worry about descriptors being held open across forks. Not to mention, you have to do a open(), write(), close() for each setting of loginuid. So I think the best solution is to make a syscall for setting the loginuid that SE Linux can protect with a distinct type. Then we can say things like local_login_t is allowed setloginuid_t. > (BTW - my 10$ says its should be a new capability since it doesn't > match either CONTROL or WRITE, I've been saying that for a while too. I think it is distinct in the same way that chown is different than unlink. Changing the loginuid is only 1 attribute in the event. CAP_AUDIT_CONTROL on the otherhand allows you to delete rules. So you change whether or not the event even was recorded as opposed to who to blame. But one thing that does help is deleting the rules is done via netlink interface, which SE Linux does control. So, policy can be written that disallows anything except auditctl_t from writing to netlink, and policy can be written saying who can run auditctl. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
RE: listening to /dev/audit in a pthread program
(Ignore my comment about /dev/audit - I wasn't thinking, yes I call audit_open) Thanks In fact I was wrong. In both cases the listener loop is in a secondary thread (gotta read my own code more closely). The differntiator is where the audit_open is called relative to the other threads. So a bit more hacking based on your reply shows the real rule :- The pid passed to audit_set_pid must be the pid that called audit_open not the pid that's listening Thanks agin. All working now -Original Message- From: Steve Grubb [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 4:13 PM To: linux-audit@redhat.com Cc: paul moore Subject: Re: listening to /dev/audit in a pthread program On Friday 20 April 2007 18:35:34 paul moore wrote: > I have an test app that quite happily does an audit_set_pid and then > sits there reading /dev/audit. There isn't a /dev/audit in linux.org kernels. > It works fine if its in the lead thread. But when I run the same code > in my real app it runs in a different thread. The important detail is where the audit_open call is made. Netlink want to send it to the same tid. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: (no subject)
On Friday 20 April 2007 18:13:17 paul moore wrote: > My understanding is that the auid/loginid process property is to allow the > audit system to *really* know who did things In particular it seems to be > for tracking who did things when they run su or sudo Yep. > But it seems to be trivial to spoof it > > login as: paul > [EMAIL PROTECTED]'s password: > Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101 > [EMAIL PROTECTED] ~]$ sudo bash > [EMAIL PROTECTED] ~]# cat /proc/self/loginuid > [EMAIL PROTECTED] ~]# echo 600 > /proc/self/loginuid But you will generate an audit message right here saying that you changed the loginuid. While its not protection, it doesn't quietly let that occur. > I was 556 at login, after sudo i am still 556 but then as root I can now > change it to 600 and the audit log for my actions has auid=600 in it > doesnt that undermine the whole point of the login id? There should still be a trail showing that you changed it. > Surely once it has been set it should not be possible to change it again. I think there are 1 or 2 daemons that count on that. > I see a debate in the thread "proc_loginuid_write() checks wrong > capability" about who should be able to do this but it misses the point. It > should only be writtable if its -1 at the moment. Otherwise it must be > unconditionally rejected. Except in the case where daemons are changing loginuid temporarily to record the fact that its doing something on behalf of a user. For example, I think postfix may do this when delivering email and reading the dot files. > The argument for it being like it is is that root is all powerfull so they > should be allowed to do anything. But the beauty of auid is that it lets me > see who the root sudoer really is. But there is a problem here...if you strip the CAP_AUDIT_CONTROL bit and and admin does a restart of sshd, sshd will not be able to set it either. If you only allow setting auid if its non-zero, how do you restart a service like sshd since it will inherit the loginuid? The only option is to reboot the machine, so forget about rpm upgrades. I really think the answer is to protect this with SE Linux policy...but there is a problem. I think that by setting loginuid by the proc filesystem we won't be able to have a SE Linux type that is distinct for loginuid without changing things in the kernel. Then you also have to worry about descriptors being held open across forks. Not to mention, you have to do a open(), write(), close() for each setting of loginuid. So I think the best solution is to make a syscall for setting the loginuid that SE Linux can protect with a distinct type. Then we can say things like local_login_t is allowed setloginuid_t. > (BTW - my 10$ says its should be a new capability since it doesn't match > either CONTROL or WRITE, I've been saying that for a while too. I think it is distinct in the same way that chown is different than unlink. Changing the loginuid is only 1 attribute in the event. CAP_AUDIT_CONTROL on the otherhand allows you to delete rules. So you change whether or not the event even was recorded as opposed to who to blame. But one thing that does help is deleting the rules is done via netlink interface, which SE Linux does control. So, policy can be written that disallows anything except auditctl_t from writing to netlink, and policy can be written saying who can run auditctl. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: listening to /dev/audit in a pthread program
On Friday 20 April 2007 18:35:34 paul moore wrote: > I have an test app that quite happily does an audit_set_pid and then sits > there reading /dev/audit. There isn't a /dev/audit in linux.org kernels. > It works fine if its in the lead thread. But when I run the same code in my > real app it runs in a different thread. The important detail is where the audit_open call is made. Netlink want to send it to the same tid. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
RE: listening to /dev/audit in a pthread program
Sorry Redhat es4 x86 monoproc Kernel 2.6.9-34.EL Audit 1.0.12-1.EL4 gcc 3.4.5 (redhat's) -Original Message- From: Paul Moore [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 3:45 PM To: paul moore Cc: linux-audit@redhat.com Subject: Re: listening to /dev/audit in a pthread program On Friday, April 20 2007 6:35:34 pm paul moore wrote: > I have an test app that quite happily does an audit_set_pid and then > sits there reading /dev/audit. > > It works fine if its in the lead thread. But when I run the same code > in my real app it runs in a different thread. No matter what PID I > pass to the audit subsystem it complains that nobody is listening > > I did audit_set_pid(getpid...) - no (passes the pid of the manager > thread) > I did audit_set_pid(gettid...) - no (passes the pid of the LWP) > > (I dont really mean I did gettid - I did syscall(_NR_gettid)) > > I can see in the complaint message that I have given it the pid I > intended to. > I can see in gdb that my LWP id is the same as the one I send to the > audit subsystem - ie gettid worked. > > Is this a known issue? A little more information would be helpful, such as distribution (I'm guessing SuSE?), kernel version, audit userspace version, etc. -Paul "The Other One" Moore -- paul moore linux security @ hp -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
(no subject)
My understanding is that the auid/loginid process property is to allow the audit system to *really* know who did things In particular it seems to be for tracking who did things when they run su or sudo But it seems to be trivial to spoof it login as: paul [EMAIL PROTECTED]'s password: Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101 [EMAIL PROTECTED] ~]$ sudo bash [EMAIL PROTECTED] ~]# cat /proc/self/loginuid [EMAIL PROTECTED] ~]# echo 600 > /proc/self/loginuid [EMAIL PROTECTED] ~]# cat /proc/self/loginuid [EMAIL PROTECTED] ~]# exit [EMAIL PROTECTED] ~]$ cat /proc/self/loginuid [EMAIL PROTECTED] ~]$ I was 556 at login, after sudo i am still 556 but then as root I can now change it to 600 and the audit log for my actions has auid=600 in it doesnt that undermine the whole point of the login id? Surely once it has been set it should not be possible to change it again. I see a debate in the thread "proc_loginuid_write() checks wrong capability" about who should be able to do this but it misses the point. It should only be writtable if its -1 at the moment. Otherwise it must be unconditionally rejected. The argument for it being like it is is that root is all powerfull so they should be allowed to do anything. But the beauty of auid is that it lets me see who the root sudoer really is. (BTW - my 10$ says its should be a new capability since it doesn't match either CONTROL or WRITE, But if that's not possible then it should be CONTROL) Any insights gratefully received Paul Moore -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: listening to /dev/audit in a pthread program
On Friday, April 20 2007 6:35:34 pm paul moore wrote: > I have an test app that quite happily does an audit_set_pid and then sits > there reading /dev/audit. > > It works fine if its in the lead thread. But when I run the same code in my > real app it runs in a different thread. No matter what PID I pass to the > audit subsystem it complains that nobody is listening > > I did audit_set_pid(getpid...) - no (passes the pid of the manager > thread) > I did audit_set_pid(gettid...) - no (passes the pid of the LWP) > > (I dont really mean I did gettid - I did syscall(_NR_gettid)) > > I can see in the complaint message that I have given it the pid I intended > to. > I can see in gdb that my LWP id is the same as the one I send to the audit > subsystem - ie gettid worked. > > Is this a known issue? A little more information would be helpful, such as distribution (I'm guessing SuSE?), kernel version, audit userspace version, etc. -Paul "The Other One" Moore -- paul moore linux security @ hp -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
listening to /dev/audit in a pthread program
I have an test app that quite happily does an audit_set_pid and then sits
there reading /dev/audit.
It works fine if its in the lead thread. But when I run the same code in my
real app it runs in a different thread. No matter what PID I pass to the
audit subsystem it complains that nobody is listening
I did audit_set_pid(getpid...) - no (passes the pid of the manager
thread)
I did audit_set_pid(gettid...) - no (passes the pid of the LWP)
(I dont really mean I did gettid - I did syscall(_NR_gettid))
I can see in the complaint message that I have given it the pid I intended
to.
I can see in gdb that my LWP id is the same as the one I send to the audit
subsystem - ie gettid worked.
Is this a known issue?
Heres the code snippet
void listen()
{
// register for events
pid_t mytid = (pid_t)syscall(__NR_gettid);
int res = audit_set_pid(m_auditFD, mytid, WAIT_YES);
res = audit_set_enabled(m_auditFD, 1);
assert(res >= 0);
static audit_reply reply;
while (true)
{
res = audit_get_reply(m_auditFD, &reply, GET_REPLY_BLOCKING, 0);
if (res < 0)
{
printf("exit audit %d %d\n", res, errno);
break;
}
printf("got event %.*s\n", reply.msg.nlh.nlmsg_len, reply.msg.data);
}
}
The thread sits waiting on the audit_get_reply call, so the FD is open
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
command missing
Hi, I've just started using auditing utilities to monitor filesystem events. I'm using audit-1.5.2 version. The problem is as follows: If I do "auditctl -a entry,always -w /etc/passwd", then "grep man /etc/passwd", then "ausearch -f passwd", the "grep" command is logged in the log file. However, if I do "auditctl -a entry,always -w /etc", then "grep man /etc/passwd", then "ausearch -f passwd", the "grep" command is not logged in the log file. However, the "vim" command is recorded if I use vim to open that "/etc/passwd" file. Is this the preassumed behavior for the auditing system or have I misconfigured something? Any clues on that? ps: Is there a better way to monitor the whole filesystem behaviors, such as open, create, delete syscalls, instead of just monitoring a single directory? Thanks for your help, Xi -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
