Using the Solaris Security toolkit to implement DISA security guidelines

Update: 8/16/12  This is a very old blog entry. However, I've had several requests to update the link for my Security Toolkit profile for Solaris 10.  Caveat.  This is based on a very old version of the DISA STIG and older versions of Solaris.  I do not warrant that this will make your system STIG compliant with the current STIG but it can be a baseline for your own customizations.  The Toolkit itself must be downloaded from My Oracle Support. (document ID 1004565.1)

Download my SST profile from 2007

You might remember my earlier blog entry about DoD security guidelines for Solaris.  As a result of Sun Federal's recent contract award from DISA for Capacity Computing services, I've been working to implement the DISA Security Technical Implementation Guidelines (STIGs) using the Solaris Security Toolkit (Wow, what a mouthful).

I started with some customization work that was done by the DISA GCCS program office.  I modified and updated it to meet most of the current STIG requirements.  I've heard many horror stories about how long it takes to secure a system properly and obtain "Authority To Connect" to a DoD network.

 I'm happy to say that the profile I've built runs in about 2 minutes on my Acer Ferrari 3400 laptop.

 First, some background!

What is the Solaris Security Toolkit?

The SST is a toolkit produced and supported by Sun to simplify and automate the process of securing a Solaris system.  The current version 4.2 support Solaris 8, 9 and 10.  It includes audit and undo modes in addition to the hardening mode.  If you plan to use it, make sure that you also apply the latest patch 122608 from  It is very customizable for your site requirements.  I have been trying to get the DISA Field Security Office to adopt and customize the SST for over two years but have not yet succeeded.

What are the STIGs?

These are security guidelines provided by the DISA Field Security Office to DoD users for securing Solaris and other Unix/Linux platforms.  Most of the recommendations make sense but there are a few silly ones.  There is a detailed book as well as a checklist and somewhat automated set of Security Readiness Review (SRR) scripts to check the work that you've done.  The scripts are NOT perfect and sometime provide false findings.  More on that later.

What were your results?

I downloaded and ran the latest DISA SRR scripts from March 2007 before applying the SST and afterward. I also ran the little script below to finish up the final few operations. During the "Manual Review" portion, I answered "Not a finding" for all the questions.  This means that the differences listed here are those detected by the automated portion of the SRR. 

Finding Counts:
CAT I = 5/123, CAT II = 53/340, CAT III = 11/57, CAT IV = 1/5

Finding Counts:
CAT I = 4/123, CAT II = 13/340, CAT III = 4/57, CAT IV = 0/5

Some of the remaining findings are false positives or out of the scope of the toolkit.  Some examples include:


 Finding Category (1 is highest)
 Recommended patches not installed
They are but the script doesn't appear to  detect them properly
Core Dumps not disabled
They are but the script doesn't detect properly
inetd disabled
It's enabled but the script looks in inetd.conf which is no longer used in Solaris 10
Various Sendmail configuration file issues
1 and 2
Sendmail is disabled with svcadm
IP forwarding should be disabled
Script looks for /etc/notrouter which is no longer used.  Solaris 10 uses routeadm.


 Great, I want it now, what do I do?

  1. Install Solaris
  2. Install the latest recommended patches for Solaris (SunSolve access required)
  3. Download and install the Solaris Security toolkit
  4. Download and install the SST patch 122608. (SunSolve access required)
  5. Download this tarball containing the customized files and User Guide (please read the User Guide)
  6. cd /opt/SUNWjass
  7. tar xvf <path to tar file>
  8. Execute: time /opt/SUNWjass/bin/jass-execute -d /opt/SUNWjass/Drivers/ -o <output file>
  9. Reboot your system
  10. Run the SRR scripts


  • I have NOT tested this in a production DoD site or run it with a DISA security officer observing.  I have only tested it on my laptop using Solaris 10 11/06.
  • Use this profile at your own risk.  I am providing it for your convenience and provide no warranty.
  • The SST profile cannot automate everything or install anti-virus software as required.
  • I have an additional script that does some final items. (see below)

Benefits of the Solaris Security toolkit

  • Because it is automated, it can produce repeatable, predictable results
  • Because is supports Solaris 8, 9 and 10, (on both Sparc and X64/86 platforms) it can be used throughout your enterprise
  • Because it is provided, supported and updated by Sun, it can be depended upon to "do the right thing" as Solaris is updated.
  • It can be used in the global or non-global zones of Solaris 10.
  • It is easily customized for your particular site requirements.
  • It has an "undo" feature
  • Speed and accuracy.  The toolkit can complete in a few minutes what would normally take hours of error prone text editing.
  • Simple.  A single command does all the work.


I'm interested in your feedback on how it worked for you, where my errors are and what additional capabilities you have given it.  Add a comment below. 

A quick script to do a little more.

Because of a lack of knowledge of the tool and lack of time, this script completes the last few operations

# This script attempts to complete the processes not done by the JASS toolkit
# items here are those documented in the User's guide
# They are here because I have not yet implemented them as part
# of th STIG toolkit
# 12/21/06 jlaurent

# tighten permissions on the Man pages
echo "Current man page permissions"
ls -ld /usr/share/man
ls -ld /usr/share/info
ls -ld /usr/share/infopa
ls -ld /usr/sfw/share/man
echo "Setting man page perms to 644"

find /usr/share/man -type f -exec chmod 644 `{}` \\;
find /usr/share/info -type f -exec chmod 644 `{}` \\;
find /usr/share/infopa -type f -exec chmod 644 `{}` \\;
find /usr/sfw/share/man -type f -exec chmod 644 `{}` \\;
echo "New man page permissions"
ls -ld /usr/share/man
ls -ld /usr/share/info
ls -ld /usr/share/infopa
ls -ld /usr/sfw/share/man

#same for various other files and directories
echo "Current /var/audit permissions "
ls -ld /var/audit
echo "Setting /var/audit perms to 700"
chmod 700 /var/audit
echo "New /var/audit permissions "
ls -ld /var/audit

#same for various other files and directories
echo "Current /etc/ftpd/ftpusers permissions"
ls -ld /etc/ftpd/ftpusers
echo "Setting /etc/ftpd/ftpusers perms to 640"
chmod 640 /etc/ftpd/ftpusers
echo "New /etc/ftpd/ftpusers "
ls -ld /etc/ftpd/ftpusers

echo "Current permissions for at.deny, at.allow, cron.deny, cron.allow"
ls -l /etc/cron.d/at.deny /etc/cron.d/at.allow /etc/cron.d/cron.deny /etc/cron.d/cron.allow
echo "Set permissions at.deny, at.allow, cron.deny, cron.allow for to 600"
chmod 600 /etc/cron.d/at.deny /etc/cron.d/at.allow /etc/cron.d/cron.deny /etc/cron.d/cron.allow
echo "New permissions for at.deny, at.allow, cron.deny, cron.allow"
ls -l /etc/cron.d/at.deny /etc/cron.d/at.allow /etc/cron.d/cron.deny /etc/cron.d/cron.allow

echo "Current traceroute permissions "
ls -l /usr/sbin/traceroute
echo "Setting traceroute perms to 4700"
chmod 4700 /usr/sbin/traceroute
echo "New traceroute permissions "
ls -l /usr/sbin/traceroute

echo "Current /etc/inet/inetd.conf permissions "
ls -l /etc/inet/inetd.conf
echo "Setting /etc/inet/inetd.conf perms to 440"
chmod 440 /etc/inet/inetd.conf
echo "New /etc/inet/inetd.conf permissions "
ls -l /etc/inet/inetd.conf

echo "Current /etc/syslog.conf permissions "
ls -l /etc/syslog.conf
echo "Setting /etc/syslog.conf perms to 640"
chmod 640 /etc/syslog.conf
echo "New /etc/syslog.conf permissions "
ls -l /etc/syslog.conf

echo "Current /var/crash permissions "
ls -ld /var/crash
echo "Setting /var/crash perms to 700"
chmod 700 /var/crash
echo "New /var/crash permissions "
ls -ld /var/crash

# changing root umask to 077 in /root/.profile and /root/.cshrc
echo "Changing root umask to 077 in /root/.profile and /root/.cshrc"
cat /root/.profile |sed "s/umask .../umask 077/g" > /root/.profile.tmp
mv /root/.profile.tmp /root/.profile
cat /root/.cshrc |sed "s/umask .../umask 077/g" > /root/.cshrc.tmp
mv  /root/.cshrc.tmp /root/.cshrc

echo "Please review the umask for .profile"
grep umask /root/.profile
echo "Please review the umask for .cshrc"
grep umask /root/.cshrc

# disable core dumps
echo "Original core configuration"

echo "Disabling core dumps"
coreadm -d global
echo "New core configuration"

Why should you care?

 Securing a computer for use on the DoD networks can be a difficult and time-consuming task.  These tools will help you deliver you mission faster, more reliably and securely.


Hi Jim.
Nice post.
I have one request: the tar file is reporting not found. Can you repost it?
And one question: why didn't you modify the driver to include the extra steps, instead of creating a new script?

Posted by guest on June 25, 2012 at 10:48 AM EDT #

Thanks for commenting. The link to the Tarball apparently did not survive the switch from to Regardless, I'm not inclined to repost because the DISA STIGs have been updated since this original post 5 years ago and although the tool still helps, it probably is not up to date with the STIGS. See my other blog post about the DoD SST profile that has been posted on Perhaps it is being maintained and update by DoD staff.

Regarding you question about why I wrote my "finish" script. I'm not a big programmer and the SST requires that modules be able to audit, enforce and roll back changes. I was just looking to build a simple script that finishes the last 5% with minimum effort.

Posted by Jim Laurent on June 26, 2012 at 08:53 AM EDT #

I am also interested in an SST profile to comply with the DISA STIGS. I could not find anothing on regarding a profile (or your blog) - can you post a link? Would you reconsider reposting the profile so I can use it as a baseline?


Posted by Jerry on August 16, 2012 at 11:32 AM EDT #

I've updated this blog entry with a correct link to my very OLD SST profile for DISA STIGs. It is offered without warranty of any kind. Modifying it to be compliant with the newest (July 2012) STIG requirement is left as an exercise to the student.

Posted by JIm Laurent on August 16, 2012 at 01:57 PM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Jim Laurent is an Oracle Sales consultant based in Reston, Virginia. He supports US DoD customers as part of the North American Public Sector hardware organization. With over 17 years experience at Sun and Oracle, he specializes in Solaris and server technologies. Prior to Oracle, Jim worked 11 years for Gould Computer Systems (later known as Encore).


« July 2016