Friday's call went very well. We had a better than anticipated turnout, and lots of good discussion.

If you want to listen to a recording of the call, you can find it on the SST Project files page.

Don't have an hour to spend listening to the call? Here's my best effort to boil it down:

  • Minutes
    • Brief history of SST
      • SST, or the Sun Security Toolkit, started out life as a tool developed by two Sun engineers, Glenn Brunette and Alex Noordergraaf, to help them with JumpStart deployments. Eventually they added CLI execution support, then audit support. In time it was productized as JASS. It became very popular as a security customization and minimization utility. Sooner or later the name JASS conflicted with a Warcraft III scripting language, so it was then rebranded as the Solaris Security Toolkit. You'll notice the first 'S' doesn't stand for 'Solaris' anymore, now it stands for 'Sun.' More on that later.
      • Fast forward to the Solaris 10 Update 4 days. SST made it to version 4.2, after which only little bits of development work went into it, mostly sustainment by the Logical Domains team who leveraged the tool to lock down the LDom control domain.
      • About two and a half years ago, Sun began the lengthy and expensive process to opensource SST. There's a very in-depth process in which the Sun engineers and lawyers review code before it is open sourced to be sure the code is really owned by Sun. There are often other company's intellectual property leveraged in source code where a complex patent licensing scheme is being leveraged. Further, it is not always clear where these other chunks of patented source actually live. So SST had to follow that same process. It made it about 90% of the way through, then it stalled.
      • At that point the fledgling SST community picked up the responsibility of completing the open sourcing process. About a month thereafter it was approved. It was at this point that the name was changed slightly. The first 'S' then went from 'Solaris' to 'Sun' because the intellectual property lawyers thought the 'Sun Security Toolkit' label had less chance of interfering with other company's products.
      • Now SST is a fully open sourced project hosted by
    • SST as an open source project
      • There are two branches
        • SST:LV - Sun Security Toolkit: Legacy Version
          • LV will remain as close to SST 4.2 as possible. Most of the work here will be break-fix and regression testing. The first open sourced LV version will be 5.0. This will provide some continuity with the legacy 4.2 version.
        • SST:CE - Sun Security Toolkit: Community Edition
          • CE will start life at version 1.0. It is here that the community will roll in exciting new features.
      • What it's not - SST solves a different problem set than these projects.
        • Secure by Default (SBD): SST and SBD may interact, but each tool addresses a different problem set.
        • Image Packaging System (IPS): SST provides application configuration functionality, but it's not a packaging tool. There might be an opportunity for SST to be leveraged by IPS, but again, each tool addresses a different problem.
    • Goals
      1. Legacy Solaris 10 support
      2. Cross-platform support
        • We want to port SST to other UNIX-like operating systems. Administrators often maintain heterogenous networks that host a myriad of UNIX flavors. It would be useful to be able to apply the same security posture to the entire enterprise.
        • We would like to port SST:CE 1.0 to
          1. RHEL and RHEL variants (Fedora, CentOS, Oracle Unbreakable Linux)
          2. OpenSolaris variants like Belenix and Nexenta
          3. Other GNU/Linux distributions like Ubuntu, etc.
          4. Other UNIXes like AIX, HP-UX, etc.
      3. Get out of the way of patching and upgrades
        • Older implementations of JASS would thrash with patching by stepping on configuration files.
        • This problem is largely alleviated by the Service Management Facility (SMF), but we need to continue working on that.
      4. Supportability
        • SST needs to not only be supportable by the open source community, but also by the administrators who use the tool to implement their security policies. Since it is written in shell, the tool is already easy for administrators to learn and extend; that's a feature that needs to be protected.
      5. Integration
        • It makes a lot more sense to have a generally-agreed upon security posture for both the OS and applications. Oracle open source projects might be a good place to start. We could provide a MySQL driver, a GlassFish driver, etc.
        • A possible integration point is with revision control systems. SST changes could, instead of on the local file system, be stored in a revision control repository like Subversion or Mercurial.
        • Better PKG and SMF integration. There are CRs that Glenn Brunette opened against SMF that describes a scenario in which you can just enable and disable configurations with SMF as opposed to services. (The bug numbers need to be looked up.) This is not to be confused with daemons that are being migrated away from flat files to SMF properties. These CRs would support the modification of configuration files for non-SMF aware binaries. Here's another opportunity to work with another OpenSolaris project.
      6. Standards
      7. Scalability
        • LDAP / SST integration could provide a UNIX answer to Windows Active Directory group policies. This could be a challenging effort, though, since the community seems to support keeping the tool in a simple language like shell or ksh93.
        • Possible XML description of finish and audit scripts. This could be tricky if SST is to stay with sh or ksh.
        • The possibility was suggested of wrapping the sh or ksh scripts with Python. A careful cost-benefit analysis would need to be undertaken.
    • Use Cases
      1. Initial installation
        • IPS or JumpStart can handle most of the initial installation use cases. SST would address this use case: An enterprise with many organizations has one group that is in charge of generating OS baseline loads. That group is able to make a baseline that meets 90% of the needs of the enterprise. Another group consumes that standard load, but needs to apply their 10% of security and configuration changes.
        • SST could be used to apply those 10% changes.
      2. Mission system
        • An administrator is given responsibility over an already running system that hosts mission applications. The system is in an unknown security state.
        • The administrator could use SST to:
          1. Audit the system to determine its current security posture
          2. With a file system snapshot (ZFS or anything else that supports snapshots), the administrator can try applying a corporate standard SST driver. Then, the administrator can regression test the mission applications and determine whether or not to roll back to the snapshot.
      3. Security audit
        • An organization has a requirement to regularly audit their information systems to ensure compliance with security standards.
        • The SST audit feature addresses this use case.
      4. Software license compliance
        • There is an alternate threat model to the traditional ones considered by the system administrators. Many systems run applications that are the intellectual property of another entity; those applications are licensed. Consider an application that does not leverage the native package management system, and that is deployed via tarball. There is no programatic way for the organization to find that software or determine its version number. The other entity could demand an audit the organization's compliance with the software license. Even though not malicious code is at play, being out of compliance with that license threatens the mission of the system.
        • Organizations could write SST audit scripts that would be specialized to find and analyze third party software. Alternatively, those third parties could provide a SST audit script with their application specifically to help with license compliance.
      5. Application configuration
        • Already discussed
      6. Standards implementation
        • An organization has a requirement to adhere to a standard like SCAP or ISO27001.
        • SST (LV and/or CE; TBD) could provide a driver with associated finish and audit scripts that implement the required standards in a trusted and consistent way.
    • Way forward
      • CDDL headers need to be added to man pages.
      • We need to roll a new installable package, then regression test SST 4.2 against a supported environments matrix. Then we can release SST:LV 5.0.
      • Many SST:CE decisions need to be made
        • Language: sh, ksh, Python, Java, etc.
        • First non-Solaris supported platforms
        • First tool driver (i.e., CIS benchmark)
        • First standard driver (i.e., SCAP)
      • Determine SST:LV support status with Oracle support management
There's a lot of information there. Email me at jason dot callaway at oracle dot com if you notice any mistakes or omissions. In the coming weeks I'll break that down to more digestible elements and post it to the community page.


Read More about [Minutes from 4 June 2010 conference call...