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: > > > > 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 I'm sorry, I thought steve was referring to credentials in the sense of changing keys/etc while crypto operations were in flight. If you're referring to users credentials in terms of permissions to use a device or service, then I think its all moot anyway. As you say why should credential changes care about crypto ops when they don't care about other ops. If you have permissions to use a device/service, changing those permissions doesnt really change the fact that you're in the process of using that service. We could do some modicum of credential check when requests are submitted and deny service based on that check, but anything already submitted was done when you had permission to do so and should be allowed to complete. Neil -- 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
