Minutes from 4 June 2010 conference call

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 at play.  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 OpenSolaris.org. 
    • 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.

Thanks,
~Jason


Comments:

Hi Jason,

My name is Matthew Flanagan and I'm a long time user of JASS/SST and I hoped to dial into the conference call last week but the timing didn't work out too well for me :(.

I've been listening to the recording and have a few comments on some of the discussion. Most of my comments revolve around porting SST to something like puppet/bcfg2/chef/cfengine. Something that is cross-platform and works to maintain the config you have built with SST as well as allowing you to just deploy it once and maybe running an audit now and then.

Cross platform abstraction - puppet does this for many OSes already including solaris and a number of BSDs and linux distros.

LDAP integration - storing xml drivers/profiles in LDAP. This would be the puppet equivalent of a manifest. This may be stored on a puppet server and distributed to puppet clients or it can be distributed how ever you want to and then run on a standalone system.

There also was some comment regarding reluctance of some shops to deploy a config management tool such as puppet or additional shells like ksh93. Building a puppet client server infrastructure is not trivial but is not required as puppet can be run in standalone mode on a single system, much like SST can be run today. Porting SST to something like puppet does not negate this use case. Puppet's requirements are minimal (ruby, and a ruby module called facter).

I actually began working on this port myself a few months back but haven't gotten too far due to lack of time.

I was pleased to hear the other conference call attendees mention puppet/chef/cfengine and I'm hoping that we can have some more healthy discussion about them for SST.

cheers

Matthew

Posted by Matthew Flanagan on June 06, 2010 at 08:29 PM EDT #

As a long time user of JASS and Jumpstart, it seems like these tools are converging with the Ops Center tools - see all use cases above.
I suggest working to make sure that the tools and methods are aligned in both projects.

Posted by Yonah Russ on June 26, 2010 at 07:41 AM EDT #

FYI:
ksh93 is available on Windows as part of UWIN and Cygwin.
ksh93 has XML plug ins.

Posted by Olga Kryzhanovska on July 02, 2010 at 12:13 AM EDT #

Wrapping a concise toolkit in extensive (heavy) frameworks, which have a lot of dependencies is a waste of time. When system admins upgrade the OS or underlying dependencies, too many things break, and those appliications which require those frameworks are sunsetted. Basic reasonable assumptions: - A toolkit should have a command line, which can operate over a socket. - If a tool kit offers a TTY with appropriate environment variables, offer a full screen mode (i.e. via curses) or highe level paneling framework (i.e. FMLI) - If environment variables can be seen to offer full screen mode with a menuing environment in an X Windows environent (i.e. XFMLI), engage it - If environment variables can be seen which just offer X Windows (i.e. DISPLAY), engage it (i.e. wksh) - If environment variables (i.e. REMOTE_USER) can be seen which offer web interface engage it. Heavvy frameworks are not required for basic things such as this. With modern browser support of SVG, even analytics can be done without extensive frameworks on the server. Wrap the tool in a basic shell script which looks at these items, searches for available server or client libraries, and engage them. As soon as heavy frameworks are required, that will offer a level of complexity that will normally restrict the usage of that feature, or kill a product. As an example, the Solaris 10 net-snmp implementation does not provide a graphical MIB Browser... what kind of broken implementation is that? It is in there, but the pre-requisite libraries were never included in the implementation. That feature is dead & broken - what junk.

Posted by DavidH on May 24, 2011 at 06:26 AM EDT #

@David - I'm not sure I understand your point. SST leverages OS-native features where available; SMF is an example. Adding support for GUIs and sockets would make the framework heavier, which you argue against. Can you please be more specific about how you would change SST?

Posted by Jason Callaway on May 24, 2011 at 06:49 AM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Jason Callaway

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today
Feeds