----- "Neil Horman" <nhorman@xxxxxxxxxx> wrote:
> On Tue, Aug 10, 2010 at 09:24:31AM -0400, Steve Grubb wrote:
> > > Thats why I had suggested the use of a netlink protocol to manage this kind
> > > of interface. There are other issue to manage there, but they're really
> > > not that big a deal, comparatively speaking, and that interface allows for
> > > the easy specification of arbitrary length data in a fashion that doesn't
> > > cause user space breakage when additional algorithms/apis are added.
> >
> > 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
--
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
