On Tue, Aug 10, 2010 at 11:40:00AM -0400, Miloslav Trmac wrote:
> ----- "Neil Horman" <nhorman@xxxxxxxxxx> wrote:
> > On Tue, Aug 10, 2010 at 10:47:14AM -0400, Miloslav Trmac wrote:
> > > ----- "Neil Horman" <nhorman@xxxxxxxxxx> wrote:
> > > > On Tue, Aug 10, 2010 at 09:24:31AM -0400, Steve Grubb wrote:
> > > > > The problem with the netlink approach is that auditing is not as good because
> > > > > netlink is an async protocol. The kernel can only use the credentials that
> > > > > ride in the skb with the command since there is no guarantee the process has
> > > > > not changed credentials by the time you get the packet. Adding more
> > > > > credentials to the netlink headers is also not good. As it is now, the
> > > > > auditing is synchronous with the syscall and we can get at more information
> > > > > and reliably create the audit records called out by the protection profiles or
> > > > > FIPS-140 level 2.
> > > > >
> > > > > -Steve
> > > >
> > > > I think thats pretty easy to serialize though. All you need to do is enforce a
> > > > rule in the kernel that dictates any creditial changes to a given context must
> > > > be serialized behind all previously submitted crypto operations.
> > > That would be a bit unusual from the layering/semantics aspect - why
> > should credential changes care about crypto operations when they don't
> > care about any other operations? - and it would require pretty
> > widespread changes throughout the kernel core.
> > > Mirek
> >
> >
> > I'm sorry, I thought steve was referring to credentials in the sense of changing
> > keys/etc while crypto operations were in flight.
> The audited values are mainly process/thread attributes: pid, ppid, {,e,fs}[ug]id, session id, and the like. Most of these are attached to the netlink packet, and performing a lookup by PID is at packet handling time is unreliable - as far as I understand the netlink receive routine does not have to run in the same process context, so the PID might not even refer to the same process.
> Mirek
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. And
in the event that happens, Audit should log a close event on the fd inquestion
between the operations.
Theres also the child process case, in which a child process might read
responses from requests sent by a parent, and vice versa, since fork inherits
file descriptors, but thats an issue inherent in any mechanism you use,
including the character interface, so I'm not sure what the problem is there.
--
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
