On Tue, May 13, 2008 at 11:24:33AM -0400, Dan McDonald wrote: > Had to pick at two tiny things...
Please :) > On Tue, May 13, 2008 at 10:10:10AM -0500, Nicolas Williams wrote: > > - I assume that [it goes without saying that] IP_SEC_OPT requests that > > conflict with whatever option is dictated by IKE/SPD config will > > fail. > > Right now, per-socket always overrides SPD unless the per-socket request is > "always cleartext", in which case, you need privilege. If you're concerned > that this current model will sabotage Labeled IPsec, please speak up. We may > need to address this anyway, as a knob which disabled this behavior was > yanked out sometime in S9 or S10 by accident. Ah. I'm thinking that asking for protection when the SPD would bypass is always OK and shouldn't require privilege -- if the app does something stupid (e.g., ESP with conf. prot. only and no AH) it will still get better security than it would if it didn't use IP_SEC_OPT at all. BUT, if the SPD provides any protection, then app should have to be privileged in order to override any aspect of that protection, OR, at the very least, what the app requests should be "better" than what the SPD provides, for some definition of "better" that isn't hardcoded. Relative cryptographic algorithm strength is hard to establish and varies as cryptanalysis of each algorithm progresses at different rates; this must therefore not be hardcoded. But I think we can reasonably say that tunnel mode provides more security than transport mode, at least when only ESP is being used. Specifically, if there's any way that the app can use IP_SEC_OPT to leave CIPSO unprotected when it's the only way of carrying the label, whereas the SPD would do otherwise, then that'd be Bad (tm). No? Nico --
