----- "Neil Horman" <nhor...@redhat.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to