On 4/03/09 11:26 AM, James Carlson wrote: > Erik Nordmark writes: > >> James Carlson wrote: >> >> >>> Rather than adding new strict_src ndd tunables, I would like to see us >>> just add a simple "strong-ES" flag that does both and get rid of the >>> old strict_dst. >>> >> Getting rid of the old means that customer's scripts which set >> strict_dst would break. We could introduce a strong-ES ndd variable (or >> per-interface flag) which has the semantics of "strict_dst + strict_src" >> if we assume that most users that care would want both semantics instead >> of just one half. >> > > We never really did give much stability to these ndd things, precisely > because they were so hackish in usage. > > Breaking strict_dst on a Minor release boundary wouldn't offend me > much, and with OpenSolaris claiming Major release binding, I think > it's just irrelevant. There's no upgrade path planned (as far as I > know) from S10 to anything -- the path from there goes into > S10-branded zones, and not a system upgrade. >
Given that the ... official use of ndd to do these things is... questioned, is there room here to take another path, such as printing a warning message when working on "old" variables that we intend to deprecate? >>> It's probably something that could be reasonably defined as an IP >>> interface flag, but if it's just an IP global, I wouldn't complain too >>> much. Either way, strong-ES completely breaks routing, so I likely >>> wouldn't want to use it. ;-} >>> >> The way strict_dst is implemented it can be used on a router (it only >> applies to interfaces that do not have ILLF_ROUTER set) >> > > I didn't say you couldn't turn on strict_dst and then "exempt" some of > the interfaces from those restrictions by setting the "router" flag. > Instead, I said that strong-ES (as defined) doesn't work with routing. > Our strict_dst implementation just makes the two states mutually > exclusive: you either get forwarding on an interface or strict_dst, > but you can't get both. > Having it coupled with the "router" flag may not be ideal, but being able to control it on a per-interface basis could be of benefit. Although the defined strong-end model results in the restrictions being disabled when forwarding is turned on, if there was a third position for that knob that allowed for that behaviour even when routing, I'm sure people would appreciate that. Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/security-discuss/attachments/20090304/d440f3eb/attachment.html>
