Tony Nguyen writes: > James Carlson wrote: > - support IPfilter configuration generated by other tools. Our framework > should satisfy the needs of most casual users. However, advanced users > can always use tools such as FirewallBuilder to generate IPfilter rules > that can be consumed by the proposed framework.
They could import those rule sets only as batches of custom IP Filter rules, and not as higher level policies, right? > > If no viable standards exist, and we don't want to create one for > > some reason, is it at least possible to synchronize policy among > > cooperating Solaris machines? I see only "system-wide" as the > > largest grouping described in the document. > > Synchronize? Do you mean configuring a policy and populate that policy > to other machines? Yes. Suppose I own more than one machine at a single site. I'd like to make sure that my machines at least have a consistent set of base policies for my site. I may need to "tweak" one or two of the machines for the needs of special applications, but I certainly don't want to redo all of this configuration work on each one or (worse) deal with rolling out changes across the machines by logging into each one, entering a GUI, and redoing a series of mouse clicks. If I recall correctly, managing multiple machines was one of the (now lost) features of Sun Screen. > > Has any investigation been done on interoperability and deployment > > with multiple machines? > > Can you clarify? > > I've run it on my desktop and multiple lap machines and some preliminary > tests with CIFS server/client. No, that's not what I meant. I meant the ability of a system administrator to set the same or similar policies on multiple machines; not just Solaris, but AIX, Linux, BSD, Windows -- all the things a real site would likely have. Especially in security, having consistent policies is a key benefit. That's why (for instance) many of our customers use either sudo or a third party product. It's not that they don't recognize the benefits of our more flexible product or better integration, but that they value consistency across platforms, which we don't deliver, and are often willing to pick a less-capable product to get it. This goes back to the question regarding comparisons with other available solutions: who is the user, and how do the needs among users differ? > > Would it be possible to have something like "tcpdmatch" for this > > tool? > > > > Very good suggestion and would be really helpful for testing. At this > point, I don't think we'll include this in our initial integration but > it will be on my list of enhancements. OK; sure. Enrico Perla writes: > > I believe such standard doesn't yet exist since IPfilter rules are quite > > flexible. Darren will correct if I'm wrong :^) > > > > I guess (James will correct if I miss something :P) that the idea here is to > create an high-level meta-language. Pretty much what happens with binary > analysis: you create a meta-language and an interpreter for that language > and than you just have to "port" the different machine codes (UltraSPARC, > x86, PPC, etc) to that meta-language and you can investigate them with > standard (and tested) primitives. Exactly. The policy rules that this project proposes are already such a language, although not exactly expressed that way. Notably, it's a restricted language. If you want to do something "fancy," you have to supply custom IP Filter expressions to do it. I don't expect a common language to do everything (nice if it could, but not expected), but there ought to be parts that everyone can do or there's not much point in creating a higher-level language. > It might be worth a try for not too obscure configurations. > The advantage is that the tool would be quickly ported to all the systems, > it could understand the state of different boxes with different operating > systems on them and it might be very handy in migration : users with a > working configuration on FreeBSD or Linux might just import that > configuration in the framework, install OpenSolaris and export it. Yes. In fact, that's what some of the other firewall-building systems have already done. Part of my question here is whether that'd ever be appropriate for the tool being proposed, and what the target user looks like. If the answer is "this isn't for people with more than one or two systems to manage, or with non-Solaris systems on hand" then that's fine. I think it helps to have a clear scope, though. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
