Scott Rotondo wrote: > Darren J Moffat wrote: >> I've given this a lot of thought and I've finally come a conclusion. >> >> Ideally I would prefer to see more (maybe not all) the changes that JASS >> makes to the default configuration made the default configuration in the >> relevant consolidations (mostly this is ON). My recent thread on >> stronger password defaults is a step in that direction. However until >> such times as we have done that AND we have somewhere in the system the >> equivalent of the JASS auditing (config check) capability I think we >> need JASS to continue. >> >> So I'm supporting this project with the main goal of it being to >> actually get as much as possible out of JASS and make it smaller as time >> goes on. I would like to see the new JASS project team work with the >> SMF and Install communities/projects to achieve this, with the ultimate >> goal being JASS is no longer a separate component or feature. >> >> I think we do need a source repository for this but I'm not sure about >> the need for a separate mailing list from security-discuss - in fact >> given that the goal is integration and the amount of work that needs to >> be done with other opensolaris.org communities I think a separate list >> initially would be detrimental to that goal. >> >> So: +1 > > This proposal has been languishing for some time waiting for another > Core Contributor to endorse it. With this email, I'm providing that > remaining +1. > > What Darren wrote above describes my position as well. My goal is to see > the security-relevant features of JASS absorbed into Solaris so that > JASS itself becomes unnecessary. I believe that should be a primary goal > of this project. In the interim, however, it is useful to make the > existing JASS source available to the broader community for maintenance > and enhancement.
I also agree with that sentiment, although I would like to stress one clarifying point. Integrating the default JASS actions into Solaris and integrating some form of auditing would be a huge step forward but that alone does not eliminate what JASS does. JASS also provides a central point for policy with respect to auditing <and> hardening. Today, we have one big knob (netservices) and lots of mini-knobs (svcadm, ndd, routeadm, mv, vi, etc.) that must all be managed independently. We don't have a flexible way for our customers to specify a policy. One of the key elements of JASS IMHO was to bring this all under the control of a single policy framework (for SMF any everything else) that allowed people to specify the hardening configuration of their systems. Without functionality of this sort, I think that any such replacement effort would be incomplete since this is a feature that is used by nearly every organization who has deployed JASS. Just my $0.02. Regardless, +1 on the project (if I have not already done so). g -- Glenn Brunette Distinguished Engineer Director, GSS Security Office Sun Microsystems, Inc.
