Softpanorama Bulletin
Vol 15, No. 03 (July, 2003)

(Slightly Skeptical)
Solaris Security Toolkit  (JASS) Notes

Dr. Nikolai Bezroukov

version 0.3

Copyright 2002-2004, Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.

Fair use:

Anyone is free to establish a link to the paper  (but mirroring is explicitly prohibited, since that could lead to an undesirable proliferation of obsolete versions).

Disclaimers:

1. The statements, views and opinions presented in this paper are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
    

2. The paper in early beta stage and would definitely benefit from a better English. Readers with strong allergy to spelling and grammar errors are advised to avoid reading of this draft.

Abstract

This paper analyses version 0.3.6 of JASS and notes presented might be irrelevant for newer or older versions of JASS. Despite IMHO dead-wrong choice of Born shell as a scripting language, version 0.3.6 looks better than previous versions. It comes with an excellent documentation. There is a rudimentary undo capability. The level of programming is not very impressive. This version contains 84 hardening modules (called "final scripts in JASS obscure terminology that is more related to the original intention to use it with Jumpstart). Most modules are quite primitive and in no way surpass capabilities of Titan. Essentially this is "me too" product. There also several driver script -- customarization scripts for typical Sun computer roles (web sever, application server, database server,  and workstation).

Introduction

The analysis below is oriented on Sun shops that mainly uses low and medium level servers.  I have no experience with high end servers like 15K.

Historically JASS started as a set of hardening scripts for Jumpstart environment, but later they were extended by Glenn Brunette to stand alone mode and that ensured the survival of the toolkit and it later adoption by Sun.  I do not understand all the fuss of using it in Jumpstart environment. The same or better results can be achieved using expect and telnet session ;-). I believe this is the result of Alex Noordergraaf  short time romance with Jumpstart ;-).

First of all I would like to note that architecturally JASS is several times more complex that Titan and that it looks that considerable part of this complexity is connected with the initial (IMHO false) idea of using it via Jumpstart.   Nevertheless JASS has an important advantage over Titan. As stated in Solaris Security Toolkit (JASS) Web site (here and below bold italic is mine -- NNB):

The Solaris Security Toolkit is not a traditional Sun[tm] product, and as such, is not supported by Sun Microsystems. However, any resulting configuration of the Solaris Operating Environment after using the toolkit is supported.

Among enhancements in the version 0.3.6 (we omit 15K-related enhancements that are connected with Alex Noordergraaf  transfer to this division and resulting interest in 15K security -- NNB):

• forced locale to "C" as the code is not fully internationalized. Does not matter much for those who do not have it.
• added set-root-group.fin script to set the root user's primary group to the value defined by JASS_ROOT_GROUP. This will help prevent that user sharing a common group identifier with non-privileged users.
• added JASS_ISA_CAPABILITY as a variable to indicate the ability of a system to operate in either 32 or 64-bit mode.
• modified make-jass-pkg to automatically determine JASS version from driver.init and to support "quiet" operation.
• included new nddconfig script which is Sun Cluster 2.x aware
• cleaned up default /etc/nsswitch.conf usage and modification

Despite IMHO dead-wrong choice of Born shell as a scripting language, version 0.3.6 of JASS looks better than previous versions in many ways. It comes with an excellent documentation. Despite using Born shell there is now a rudimentary undo capability. Still limitation of Born shell shows and neither the architecture, not the level of programming of fin scripts are very impressive. 

On a positive side I would like to stress that the toolkit also is supplied with an excellent for a such a package documentation.  It includes four very well written and thoroughly edited (unlike this notes ;-) documents:

1. The Solaris Security Toolkit -- Quick Start This article provides an administrator with the information critical to getting the Solaris Security Toolkit installed and running as quickly as possible. The article does not include the details covered in the "Installation, Configuration, and Usage Guide" or "Internals" articles. 
2. The Solaris Security Toolkit -- Release Notes This article provides toolkit users with a discussion of the new features, enhancements, and changes included in version 0.3 of the Solaris Security Toolkit.
3. The Solaris Security Toolkit -- Installation, Configuration, and Usage Guide This article focuses on the configuration and installation information of the Solaris Security Toolkit. It provides a more in-depth discussion of the installation, configuration, and usage options available in the toolkit than in the Sun BluePrints Online article titled "Solaris Security Toolkit -- Quick Start Guide."
4. The Solaris Security Toolkit -- Internals This article focuses on the internals of the toolkit, and includes discussions on each directory, file, and script included with the toolkit source.

Interesting ideas in JASS

There are two things that might be considered a steps forward in comparison with Titan:

1. There are some rudimentary attempts to systematize hardening modules by using the following classification:
   • disable
   • enable
   • install
   • remove
   • set
   • update
   • print
      
2. Despite using Born shell, there is a granular undo capability, although it was implemented as afterthought and not very clean:

   Solaris Security Toolkit (JASS) FAQ

   As of this release, hardening scripts have been categorized as either undoable or not undoable. Those scripts that are undoable have been collected into the "undoable-hardening.driver" script. Those scripts that cannot be undone are stored in the hardening.driver script. There are currently only three hardening scripts categorized as not undoable:

   • enable-bsm.fin
   • install-fix-modes.fin
   • install-strong-permissions.fin

    

3. There is also rudimentary attempt to provide several modular configuration for hardening, based on the role of the system. Technically JASS here is still on the level of Titan (In titan three examples are defined: firewall, desktop, server), but an interesting thing is that JASS is providing slightly different and rather useful for in enterprise environment roles (web server, application server, database server)

   Like in Titan, modularization includes elements of the standard structure: each driver calls driver.init at the beginning and driver.finish and the end.  The structure of the driver can be seen on the example of audit.driver which is extremely primitive but still useful:

   #ident "@(#)audit.driver 2.6 02/02/26 SMI"
   
   
   DIR="`/bin/dirname $0`"
   export DIR
   
   . ${DIR}/driver.init
   
   JASS_SCRIPTS="
   	print-suid-files.fin
   	print-sgid-files.fin
   	print-world-writable-objects.fin
   	print-unowned-objects.fin
   	print-rhosts.fin
   "
   . ${DIR}/driver.run
   

From the example above you can see that driver is calling so called hardening modules. In this particular case most of them are just envelopes for one Unix command like print-suid-files.fin above. The latter essentially contains commands necessary for execution of:

    find ${JASS_ROOT_DIR} -local -type f -perm -2000 -ls

As you can guess the interpretation of the listing is left to the user, and this is, not running find command is the most difficult part of the audit.  that means that they are doing a very poor job in this particular area.

There are 84 hardening modules ("final scripts" in JASS obscure terminology). Few are unique to JASS and do not have counterparts in Titan or other sets of scripts.  Among interesting things that I noticed are:

• install-md5.fin - Install the MD5 software for use with the BluePrint Online article titled "The Solaris Fingerprint Database - A Security Tool for Solaris Software and Files" available from http://www.sun.com/blueprints/0501/Fingerprint.pdf 
• install-openssh.fin  -- Installs OpenSSH into /opt/OBSDssh.  The distribution for which this script is outdated and is based on the July, 2001 BluePrint Online article on building the OpenBSD port of OpenSSH for Solaris. This script will not overwrite host key files if they already exist.
• install-recommended-patches.fin -- Installs a Sun Recommended and Security Patch Cluster from ${JASS_ROOT_DIR}${JASS_PATCH_DIR}.
• disable-wbem.fin -- Prevents the Web-based Enterprise Management (WBEM) service from starting by disabling the run-control scripts.

Conclusions

It looks like with addition of selected Titan modules JASS 3.6.x might be competitive tool for a large enterprise environment, which might have security analysts in Unix group staff to keep this synchronization current.  The main advantage and attraction of JASS is that while toolkit itself is unsupported, the resulting "hardened" configuration are supported by Sun. For smaller firms or firms that do not rely on Sun support Titan IMHO still has an edge.

If you ignore baroqueness of the code (partially due the desire to ensure dual use: standalone and Jumpstart environment), this version can be considered to be closer in functionality to Titan than previous ever were.

The main problem that I see from architectural view are limitations of Born shell and that shows: excessive number of global environment variable for customarization, primitive logic in most "final" scripts, etc.

The license used in JASS essentially limits custom version to a particlar enterprise, the decision that has both good and bad sides. Bad side is that it somewhat diminish enthusiasm of potential contributors (there is no attribution in modules, all of them are nameless and just listed in "acknowledgements" file).  

Last modified: March 12, 2019