On Tuesday, August 10, 2010 02:45:44 pm Neil Horman wrote: > On Tue, Aug 10, 2010 at 02:14:24PM -0400, Steve Grubb wrote: > > On Tuesday, August 10, 2010 01:57:40 pm Neil Horman wrote: > > > > > I'm not so sure I follow. how can you receive messages on a socket > > > > > in response to requests that were sent from a different socket. > > > > > In the netlink multicast and broadcast case, sure, but theres no > > > > > need to use those. I suppose you could exit a process, start > > > > > another process in which the pid gets reused, open up a subsequent > > > > > socket and perhaps confuse audit that way, but you're not going to > > > > > get responses to the requests that the previous process sent in > > > > > that case. > > > > > > > > I don't even need to open a subsequent socket - as son as the process > > > > ID is reused, the audit message is incorrect, which is not really > > > > acceptable in itself. > > > > > > But, you do, thats my point. If a process exits, and another process > > > starts up that happens to reuse the same pid, it can't just call > > > recvmsg on the socket descriptor that the last process used for > > > netlink messages and expect to get any data. That socket descriptor > > > won't be connected to the netlink service (or anything) anymore, and > > > you'll get an error from the kernel. > > > > You are looking at it from the wrong end. Think of it from audit's > > perspective about how do you guarantee that the audit trail is correct? > > This has been discussed on linux-audit mail list before and the > > conclusion is you have very limited information to work with. By being > > synchronous the syscall, we get everything in the syscall record from > > the processes audit context. > > What information do you need in the audit record that you might loose > accross two syscalls? This is easier to show that explain. With Mirek's current patch: type=SYSCALL msg=audit(1281013374.713:11671): arch=c000003e syscall=2 success=yes exit=3 a0=400b67 a1=2 a2=0 a3=7fff4daa1200 items=1 ppid=1352 pid=1375 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty6 ses=3 comm="ncr-setkey" exe="/home/mitr/cryptodev- linux/userspace/ncr-setkey" subj=unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 key=(null) type=CRYPTO_USERSPACE_OP msg=audit(1281013374.713:11671): crypto_op=context_new ctx=0 type=CWD msg=audit(1281013374.713:11671): cwd="/root" type=PATH msg=audit(1281013374.713:11671): item=0 name="/dev/crypto" inode=12498 dev=00:05 mode=020660 ouid=0 ogid=0 rdev=0a:3a obj=system_u:object_r:device_t:s0 type=CRYPTO_STORAGE_KEY msg=audit(1281013374.715:11672): key_size=16 The netlink aproach, we only get the credentials that ride with the netlink packet http://lxr.linux.no/#linux+v2.6.35/include/linux/netlink.h#L159 There really is no comparison between what can be recorded synchronously vs async. > It sounds from previous emails that, generally speaking, you're worried that > you want the task struct that current points to in the recvmsg call be > guaranteeed to be the same as the task struct that current points to in the > sendmsg call (i.e. no children (re)using the same socket descriptor, etc). Not really, we are _hoping_ that the pid in the netlink credentials is the same pid that sent the packet in the first place. From the time we reference the pid out of the skb until we go hunting and locate the pid in the list of tasks, it could have died and been replaced with another task with different credentials. We can't take that risk. > Can this be handled by using the fact that netlink is actually syncronous > under the covers? But its not or all the credentials would not be riding in the skb. > Can you ennumerate here what FIPS and Common Criteria mandate be presented > in the audit logs? Who did what to whom at what time and what was the outcome. In the case of configuration changes we need the new and old values. However, we need extra information to make the selective audit work right. -Steve -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
