James Carlson wrote: > 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?
Correct. > >>> 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. > understand >>> 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. > Most of the discussion is around the target users and project scope. I'll revised the document to clarify those points. The proposed project aims to provide framework that enables non-admin users to configure firewall on their OpenSolaris laptops and/or desktops. The Visual Panels project relies on this framework to provide a firewall configuration tool. Our goal here isn't a general firewall configuration tool which FirewallBuilder is a good solution though quite complex, IMHO :^) Policy synchronization across multiple machines is a really good suggestion that I'll investigate. Thanks you both for the valuable comments, -tony
