Glenn Brunette wrote:
>
> 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
>
Having the security policy enforced by centralized rules is obviously
the right thing to do. I spoke briefly with Scott yesterday about my
concerns that simply having new conventions may not be enough to show
signs of real improvements with Solaris security. I truly don't want to
imply this as a negative criticism, but I am encouraged that this
project may deliver some additional value if the bar is set at a higher
level.
Do you think this project can also work towards additional goals such as
non-bypassable that may be a part of other projects?
Regards,
--John
