Glenn Brunette wrote: > John Totah wrote: >> 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? >> > > Can you elaborate here? Are you looking for similar functionality > or tighter integration with other projects? If yes, what projects do > you have in mind? To date, JASS has been solely focused on just > hardening but having something more comprehensive is certainly > more interesting to me. > Honestly, I would love to see some kind of radical simplification of > security configuration and administration in Solaris on the order of > what ZFS brings to storage management. Is this where you are > going? > > g >
Basically, I am looking at this from the point of view that I believe you can only do so much within the scope of greenline. I had initially thought there are possible ways to leverage some of the new projects that I am interested to see how they will enforce and check the additional control objectives they satisfy. I suggested to Scott that valex may also be a possible candidate to ensure the system integrity also accounts for the hardened configuration, but he has explained that anything like SST/JASS is beyond what is intended for it. At one time, projects prior to rampart had requirements for trusted recovery, and there were good reasons to have a deterministic way to verify the tcb - boot time impact aside. So my only suggestion at this point is that this could be done as an umbrella project that covers all of the security configuration identified in the target consolidations. Like you've said, this must be simple, but I also see advantages to unification. My concerns are that unless this becomes more than conventions, the security policy will never be easy to evaluate. Please recall the following CCE example from http://cce.mitre.org/lists/cce_list_editorialpolicies.html EXAMPLE 2: (Solaris Services) In Solaris, services are started based upon their assigned ordering in a boot level. During bootup, first the kill service scripts are processed, then the start service scripts (in alphanumeric order) in the /etc/rc2.d/ and then the /etc/rc3.d/ directories. Therefore, there are at least two (similar) ways to disable a service at boot: (1) Remove the correct startup script (S[0-9].[service]) from the rc directories, or (2) add a kill script (K[0-9].[service]) at the next boot level to kill that service. Even though one method allows the service to start and later kills it, while the other prevents it from ever being run, they are both assign to the same CCE entry. Consider a CCE entry concerning the RCP service starting at boot-time. Two Technical Mechanisms associated with this CCE may be: + file presence - /etc/rc2.d/S71rpc + add /etc/rc3.d/K71rpc kill script + modify /etc/rc2.d/S71rpc so that the command is never run Regards, --John
