Re: [PATCH 0/4] RFC: "New" /dev/crypto user-space interface

[Steve Grubb <sgrubb@redhat.com>]

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