Thursday Jul 28, 2011

Known problem: user nobody existence

There's a known problem with the disable-system-accounts finish and audit scripts.  It doesn't seem to recognize the existence of user nobody, and produces faulty messages in both harden and audit modes.

If somebody has a fix, please send it over.  Otherwise I hope to work on this in the next few days. 

Friday Jul 08, 2011

SST:LV 4.2.2 posted

I've just posted version 4.2.2.  You can download it here.

Recently, passwd behavior was changed so that it won't lock NP accounts.  SST has been updated so that it won't either, and so that the subsequent audits won't produce false positives. 

If anybody uses this version successfully, or has used 4.2.1 with good results, please let me know.  I've tested both as well as I can in my VM environment, but SST still needs a good burn-in in a real lab. 

Sunday May 22, 2011

SST:LV 4.2.1 posted

I've posted version 4.2.1 of SST:LV.  You can download it here.

How different is this from version 4.2?  Well, not very.  It's a beta version.  What's important with this version is for the community to a) try it out on their development systems and find problems, and b) submit their fancy new finish and audit scripts to move this thing forward.

So far, it seems to work as expected in execution, audit, and undo modes in the CLI context on a Virtualbox VM running Update 9.  I haven't tested JumpStart, SPARC, bare-metal x86.  Right now I'm focusing on the server-secure driver because I think it's the mostly heavily used.  If there are other drivers that people are interested in, please let me know.

If you find some problems, drop me an email at and please include the logs from /var/opt/SUNWjass/run/<datetime>/.

One warning: if you want to use version 4.2.1 on your mission systems, use caution.  Take a backup first.  I don't think I've changed anything, but until I've done some serious testing, I wouldn't run this on my production boxes without a good backup and a bottle of scotch.

Saturday May 21, 2011

hg on Solaris 10 x86 Update 9

Every time I need to install mercurial on Solaris 10 I find that I've forgotten how to do it.

So here it is.  By the way, I installed the s10u9 SUNWCXall package metacluster on x86, so if you installed a lighter system or a different version, you might need more prereqs.  From Sunfreeware, download and install in this order:

  1. libgcc-3.4.6-sol10-x86-local.gz
  2. openssl-1.0.0d-sol10-x86-local.gz
  3. python-2.6.2-sol10-x86-local.gz
  4. mercurial-1.8.3-sol10-x86-local.gz

You could probably do some path ninjary to make the native packages jive with hg, but if you're lazy like me this is easier.

Thursday May 19, 2011

And we're back

Don't know if anybody follows this anymore, but I'm working on this project again.

I used to try and explain how the attention of a consultant shifts frequently with the needs of his or her customer, but not to worry, because more development cycles were right over the horizon.  But then I realized that a) nobody cares, and b) it doesn't help anyone for me to over promise and under deliver.

So where we stand now is, I'm working on this again, both Legacy Version and Community Edition.  The future direction of the latter is still somewhat uncertain as I'm trying to wrap my brain around how we're going to deal with SCAP and OVAL.

My immediate goal is to get SUNWjass 4.2.1 built and available for people to test.

Please comment or send me an email if you have any immediate needs, or if you want to just say 'hi.' 

Monday Mar 14, 2011

Blog migration

This blog will be migrated to soon.  Check back for news about where the project will go from there.

Friday Jun 18, 2010

Proposed name change

Given that cross-platform compatibility is a core development goal of this project, I think the name "Sun Security Toolkit" no longer makes sense.

I propose a name change from "Sun Security Toolkit" to "SST Security Toolkit."  


  • The community is familiar with the SST acronym.  It makes sense to leverage that familiarity.
  • There is a tradition of recursive acronyms in open source, i.e. GNU and RPM.
  • Removing the Sun brand name from the tool may encourage adoption by administrators who are unacquainted with Sun technologies.

I'd really like to hear from the community here.  The security-discuss list had little to say about the proposal with one for, one against, and one neutral.  

Anybody else?  Otherwise, qui tacet consentit.

Wednesday Jun 16, 2010

Updated project page

I've made some significant changes to the SST project page.  Most of the goodness from our recent conference call should be baked-in now.

Also, I've got something of a rudimentary task list up and running.  Surely there's a better way to manage this, but hey, baby steps.

One other note: the blog roller seems to be mis-configured somehow; I'm not receiving emails when anybody posts comments. If you've posted and I haven't responded, apologies.  I'll work on fixing that.

Sunday Jun 06, 2010

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 
    • 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.


Wednesday Jun 02, 2010

Agenda for Friday's conference call

There's been a fair amount of interest in Friday's conference call.  So here's a new number that supports more callers, and it's toll-free too.

Toll free number: 866-682-4770
Conference code: 8490295
Security code: 7781 (SST1)
Date: 4 June 2010
When: 4 pm US/Eastern


  • Brief history of JASS / SST
  • SST as an open source project
    • Branches
    • Goals
    • New functionality
  • Use cases
    • Initial installation
    • Already running system
    • Security standards and accreditation 
    • Break-in forensic analysis
    • Software license compliance
    • Others?
  • Actions / where to go from here
  • Questions

 I'll talk to you all on Friday.



Saturday May 29, 2010

So what's up with the lack of updates?

Anyone who has been following this project has probably noticed a distinct lack of activity. 

Previously, I was unable to get the development work rolling.  Obviously, I'm not able to do it alone, and even coordinating work with others requires a time commitment.  So where have my commitments been? 

Well, for my day job I'm a systems architecture consultant.  The life of a consultant is a topsy-turvy one in which one's priorities are in flux -- the customer's priorities are the consultant's priorities, but not vise-versa.

Luckily my customer's schedule has slowed down.  I hope to take advantage of this lull and give SST some momentum so it can make progress while I'm head-down in the consulting mines.

So let's revitalize SST!

Friday, 4 June 2010 at 4 PM Eastern there will be a conference call to kick off the revitalized SST effort.  Call my access line, 240-782-4407 and press \*\*, then enter the guest speaker code, 5556.  There are only 15 slots available, so if you plan on calling in, shoot me an email at and let me know.  If we get more than 15 callers I'll set up a different number (more slots, but more time consuming to set up).  

I'll post an agenda in the next few days.

SST Project Page:

Sunday Oct 11, 2009

Test and development methodology

I plan to post this to the SST project site soon.  Any feedback or recommendation would be greatly appreciated.



Bridging the gap between SST 4.2 and SST:LV 5.0 is a matter of test, analysis, and fix – and once the project actually puts hands to keyboards, it shouldn't take long.

SST 4.2 support for Solaris 10 ended with Update 4. In fact it's the 4.2 source code that is available in the Mercurial repository:

hg clone ssh://

Earlier this year Glenn Brunette, one of the original SST developers, suggested a straight forward test-fix approach. Using the audit, harden, and undo modes of jass-execute we can easily identify which Audit and Finish scripts need to be updated to support later Solaris updates.

Test phase

The test-phase will identify which .aud and .fin scripts need to be updated.  It's possible that errors will crop up in the SST infrastructure functions, but most likely that the audit and finish scripts will be the sources of incompatibility with Solaris 10 versions subsequent to Update 4.  Scripts that produce errors will be added to a Fix List and posted to the SST Project page for updating.

There will be several Fix Lists, one for each platform type.  This can be expanded, but initial Fix Lists will include:

  1. SPARC

  2. SPARC, virtualized i.e., LDoms

  3. SPARC, platform-specific, M[34589]000, 25K / 15K

  4. x86

  5. x86, virtualized, VirtualBox

  6. x86, virtualized, xVM

  7. x86, virtualized, VMware, Fusion

  8. x86, virtualized, VMware, Workstation

  9. x86, virtualized, VMware, ESX / ESXi

In beta we'll try and test against as many hardware platforms as we can. SunFed employees can use the McLean lab, which is pretty well stocked.

Stand-alone context 

Our approach is to audit, execute, then audit again and inspect the results.  We'll want to test both the stand-alone and Jumpstart contexts, but since stand-alone is a little easier, we'll start there with the following steps:

  1. Audit

  2. Harden

  3. Audit

  4. Undo

  5. Audit

Step 1

The results of the first audit become a tentative baseline – tentative because the .aud scripts may be malfunctioning. But it's a good starting point. We'll start with the server-secure.driver Driver.

# /opt/SUNWjass/bin/jass-execute -V 4 -a server-secure.driver

Step 2

Next we run the driver in stand-alone hardening mode.

# /opt/SUNWjass/bin/jass-execute -V 4 -d server-secure.driver

We would expect the execution to produce no errors, nothing tagged with [ERR ].  Any .fin scrips that error out will be added to our Fix List.

Step 3

Now we run another audit.

# /opt/SUNWjass/bin/jass-execute -V 4 -a server-secure.driver

We would expect everything to pass, i.e. [PASS].  Any .aud scrips that error out will be added to our Fix List.

Step 4

Undo the last hardening.

# /opt/SUNWjass/bin/jass-execute -V 4 -u server-secure.driver

Any .fin scrips that error out will be added to our Fix List.

Step 5

Audit one more time.

# /opt/SUNWjass/bin/jass-execute -V 4 -a server-secure.driver

Since this audit is against a (supposedly) un-hardened system, we expect a lot of .aud scripts to [FAIL].  But the list of failures should be the same as the ones produced in Step 1.  Any deltas will be added to our Fix List.

Jumpstart context 

There's less to test from Jumpstart, but you'll need a working Jumpstart environment to do it. I'd recommend using JET since it really simplifies the whole process. I'll post a how-to for JET in the next several days.

(Jumpstart context methodology to be posted shortly.)

Analysis phase

After every run of SST, results can be found in:


Each step will produce various files of interest.  These files will feed our Fix List.

  • Step 1 - Audit
    • jass-script-errors.txt
    • jass-script-failures.txt
      • For comparison to the failures produced by Step 5
  • Step 2 - Harden
    • jass-script-errors.txt
    • jass-script-failures.txt
  • Step 3 - Audit
    • jass-script-errors.txt
    • jass-script-failures.txt
      • In this case we'd hope to see everything pass since we previously ran the hardening driver. Anything that filed here could be an indicator of a problematic .fin scrip from the previous step.
  • Step 4 - Undo
    • jass-script-errors.txt
  • Step 5 - Audit
    • jass-script-errors.txt
    • jass-script-failures.txt
      • By diffing this against the failures in Step 1 we can find malfunctioning .fin scripts from Step 4.

The scripts listed in these files, and the deltas from the Step 1 to Step 5 diff should produce a good (but not necessarily complete) Fix List.

I'll post the first Fix List (x86, virtualized, VirtualBox) in a few days.

Fix phase

For every script in the Fix List we'll need to trace the logic and fix the problems.  Some scripts will probably be trivial to fix, while others will require quite a bit more effort.  The SST project doesn't have its own mailing list yet; we'll just use our endorsing community's list,

To start I'd recommend adding a set -x to the .fin script, make a custom driver that calls only that script, and re-run.


Any recommendation or comments are welcome.


Monday Oct 05, 2009

Development of SST:LV 5.0 delayed, but about to start soon

Work on this project has been slow to start, but it's about to pick up momentum. 

Later this week I'll post our development and test methodology.  By next week I hope to have two or three of my colleagues signed up to help with legacy version (SST:LV) 5.0.

With some luck we should a beta of SST:LV 5.0 available later this month.

More to come.


Monday Jun 08, 2009

Security blog mentions SST

The popular Sun Security Community Blog posted about the SST project.

I've been following the Sun Security Community Blog for some time.  Its RSS feed lives in my Google Reader.  So it was a special thrill to see SST mentioned.

JASS lives! SST project annoucement at

It's been a long time coming, but JASS has finally been open sourced.

Source code for the Sun Security Toolkit (SST) is now available on the project page at

I'm working on a few articles to post to this blog -- a history of JASS/SST, development roadmaps for both versions (Legacy Version and Community Edition), some how-to guides for contributing and testing.  I'd also like to schedule some teleconferences for the community.  SST has been out of the loop for a while, so everybody needs to get up to speed, and some consensus regarding project direction needs to be reached.

Your comments and questions are welcomed.



Jason Callaway


« December 2016