Monday Dec 16, 2013

Solaris 11.1 STIG update

I am still in the process of creating a Solaris 11.1 Security Technical Implementation Guide (STIG) with DISA Field Security Office.  The process is long and detailed requiring significant testing and review by DISA for final approval.  The STIG items are complete (pending DISA's approval).  While I can't predict how long the final approval will take, if you are a DoD customer wishing to run Solaris 11, you may contact your Oracle systems sales team to receive a draft copy in spreadsheet form.

STIGs are guidelines to assist DoD customers in securing their systems.  It is NOT required to have a DISA STIG document to run Solaris 11 in your environment.  In the absence of a DISA approved STIG, customers may use industry or vendor recommended guidelines.  We already have a number of DoD customers running Solaris 11.  Resources available include:


Our customers find that Solaris 11 is much more secure "out of the box" than Solaris 10 and is easier to bring into compliance.  Solaris 11 is now over two years old and provides significant new features and benefits for Solaris 10 including:

  • ZFS default root file system enabling:
    • Easier, safer system updates
    • Automatic alternate boot envioronments
    • Improved zone management 
    • Encrypted file systems
    • Compressed, de-duplicated file systems
    • Simplified RAID and mirror configuration
  • Image Packaging system for:
    • Faster, safer updates
    • Easier system minimization
  • Improved Security including
    • Elimination of root login
    • FIPS 140-2 certified Crypto Framework
    • Multi-level security enhancements
  • Complete network and application virtualization
  • Automated installer
  • Much more

Learn more about What's New in Solaris 11 and 11.1.


Solaris 11 Crypto Framework receives FIPS 140-2 certification

NIST has awarded FIPS 140-2 certificate #2060 to the Oracle Solaris Kernel Cryptographic Framework with SPARC T4 and SPARC T5 (Software-Hybrid), and FIPS 140-2 certificate #2061 for the Oracle Solaris Kernel Cryptographic Framework (Software) module.  The certificates are not yet available, however, the details are already posted on the NIST Validated FIPS 140-2 Website listed below.

The Userland Software and Software-Hybrid validations are still in the NIST Coordination phase.  

Thursday Dec 01, 2011

Solaris 11 compliance with DISA Security guidance


This article should not be construed as a statement of compliance by Oracle or by DISA.  It is simply the result of a casual review of Solaris 11 against current DISA Security Guidelines

Some of my dedicated readers (I know you're out there) remember that back in Janauary of this year, I reviewed Solaris 11 for compliance to the DISA Security Technical Implementation Guidelines (STIGs).  The STIGs are written by DISA and used by the DoD community to ensure that systems are secured properly before connecting to the network.

With the release of Solaris 11 in November, I decided to update the document. 

Update: Thanks to Darren Moffat's comments I've updated the document as of 12/9/11. 

Download the PDF document to review

The great news is that the one item that I listed as RED in January has been fixed in the release of Solaris 11.  At that time, the installation scripts did not provide any way for /var to be mounted as a separate file systems as required by the scripts.  The default installation now automatically sets of /var as a separate ZFS data set.

Monday Mar 10, 2008

Updated: Type Enforcement security project joins the OpenSolaris security community

Update:  Our own architect of Solaris 10 Trusted Extensions corrected me on my statements about MLS capability and Type Enforcement.  I've corrected my table.  Glenn writes in a comment:

It isn't accurate to state that Type Enforcement enables multilevel security. Although you could define relationships between various types that have similar semantics to Bell & Lepadula rules, this is not practical in general. Types, unlike sensitivity labels, don't have implicit hierarchical relationships. Instead the flexibility of the relationships between types is seen as an advantage over the more rigid MLS rules.

One reason this is confusing is that FLASK in SELinux supports both Types and MLS labels, whereas the Solaris implementation of FLASK will just focus on Types since MLS labels are already associated with zones.


Great News! 

One of the benefits of open sourcing Solaris is the ability to take advantage when "Innovation Happens Elsewhere" (to quote Sun co-founder Bill Joy).  One of the innovative projects that originated elsewhere is an implementation of Type Enforcement (aka "Flask") for OpenSolaris.  Type Enforcement is a form of Mandatory Access Control that has already appeared in the Security Enhanced Linux project first developed at NSA.  SELinux has worked its way from a science project into major Linux distributions today.

What does this mean for Open Solaris?

  • First, it means that we have active development and external contributions to the OpenSolaris community.
  • Secondly, it means that (when completed), customers and governments who prefer the Type Enforcement to Sun's own Solaris 10 Trusted Extensions model, will have that choice without having to give up the other advanced features of Solaris.

Who is doing this work?

When can I get it?

The project has only recently been created at in the OpenSolaris security community.  The source code has yet to be written and posted.   Nothing has been integrated in to the next version (Nevada) of the Solaris kernel yet and there are no plans yet for it to be in Solaris 10.  As the project progresses it may be fully integrated into the Nevada kernel and eventually find its way into a commercial release of Solaris.  Join the community to keep up to date on the latest information.

How will Type Enforcement complement the current Solaris security model?

Read Glenn Faden's most recent blog entry.

Why should I care?

If you have been looking at using SELinux in your project, you should join the community and contribute your comments, feedback, testing and even code to the project creating a better Solaris.

Monday Jan 07, 2008

Great Solaris Security recommendations by Glenn Brunette

Glenn Brunette just published an excellent blog listing his 5 favorite Solaris security features.  Among the valuable quotes are:

  • Solaris has had its auditing facility in place since Solaris 2.3, but I can't even begin to count how often I talk with people who do not know that it exists.  (I frequently get this question)
  • Zones are IMHO one of the most significant security features in the Solaris 10 OS. Kernel and most user-land forms of root kits are essentially rendered non-effective when running your applications in a sparse-root non-global zone. (I even recommend to customer when only running one application on a box to run it in a local zone for enhanced security.)
  • For those wanting something a little more advanced, you can use RBAC to implement a two-person (or four-eyes) access control scenario.  (An excellent recommendation for security conscious DoD customers

He also points you to a number of learning resources on Solaris:

Why should you care?

You chose Solaris because of its stellar reputation for security.  Don't be "living in the 90s."  Take the time to learn the new features of Solaris 10 so that you can build and maintain a more robust and secure infrastructure for your organization.

If security is your main area of interest, join the OpenSolaris security community and participate.  Don't forget to get your free download of Solaris 10 or OpenSolaris for Sparc or X64 platforms.

Monday Jul 30, 2007

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.

Wednesday Mar 07, 2007

FAQ: Securing Solaris for use in the US DoD

As an OS Ambassador at Sun who works very closely with the US DoD, I'm frequently asked how one secures Solaris for use in the DoD. The definitive source for this information is the DISA Field Security office "Security Technical Implementation Guide" (aka STIG). DISA owns and operates the data centers and neworks for the US DoD. Security checklists and about 500 pages of documentation are included. 

They can be downloaded at:

In addition, DISA provides "Security Readiness Review" scripts which audit your system and report discrepancies.  They were last updated in January 2007 and include S10 support.  The SRRs are available at:

Some DoD organizations have created a Solaris Security Toolkit profile which accomplishes about 90% of what the STIGs require. The SST is Sun's supported "security lockdown tool" that is a free download and easily customizable. It typically executes in about 4 minutes drastically reducing the time required to secure a system and providing automated, reproducible  results.  The SST also include "undo" and "audit"  functions. The SST can significantly reduce the time that it take you to reach "Authority to Operate" status on a DoD network.

The DISA STIGs require a wide variety of changes to the Solaris OS including:

  • Solaris auditing enabled with specific items being audited.
  • Basic Auditing and Reporting Tool enabled
  • root home directory changed to /root
  • McAfee antivirus installed (yes, even though it really only checks for Windows viruses)
  • Massive permissions and umask changes
  • TCPwrappers enabled
  • certain services must be disabled (FTP, Telnet etc)
  • Certain commands must be disabled (snooop, rsh, rexec etc)
  • Password history, lockout and construction settings
  • Banner page changes
  • PROM password settings
  • etc.

Other documents that might be of interest for security conscious customers include:

Why should you care?

 The US DoD takes computer security very seriously.  Their STIG documents provide a detailed definition of all the activities required to secure a Sun Solaris system.  Utilization of their tools and method can result in a highly secure data center operation.

The Solaris Security Toolkit can simply this process and make to predictable, repeatable and faster than a manual process.

For the highest level of security (equivalent to the old NSA B1 level) Solaris 10 11/06 includes the capability to at Trusted Extensions to your environment. Solaris Trusted Extensions provide full label aware services to meet the most stringent multi-level OS requirements.



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