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. The audit logs require non-repudiation. It cannot be racy or stitch together possibly wrong events. Audit logs can and do wind up in court and we do not want problems with any part of the system. > > > And in the event that happens, Audit should log a close event on the fd > > > inquestion between the operations. > > > > audit only logs explicitly requested operations, so an administrator that > > asks for crypto events does not automatically get any close > > events. Besides, the audit record should be correct in the first place, > > instead of giving the admin a puzzle to decipher. > > I still don't see whats incorrect here. If two processes wind up reusing a > process id, thats audits problem to figure out, nothing elses True, but that is the point of this exercise - meeting common criteria and FIPS. They both have rules about what the audit logs should present and the assuarnce that the information is correct and not racy. > . What exactly is the problem that you see involving netlink and audit > here? Compare whatever problem you see a crypto netlink protocol having > in regards to audit to another netlink protocol (say rtnetlink), and > explain to me why the latter doesn't have that issue as well. That one is not security sensitive. Nowhere in any protection profile does it say to audit that. -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
