Monday Aug 04, 2008

NEW: Solaris Package Companion v0.8.1 / Testing Tool v0.1

On the heels of the v0.8 release, Clive King was able to find a new bug introduced as a result of my attempting to make the code a little more in line with Korn Shell conventions. Clive, thank you for reporting the details! I have published an updated version as v0.8.1. As always, you can get all of the details at the OpenSolaris Solaris Package Companion Project Page

As is my tradition when a bug is found, I try and publish a little something extra as a mea cupla. This time is no different. In addition to version 0.8.1 of the Solaris Package Companion, I have also published a testing tool for the same.

The testing tool, called spc-test-v0.1.ksh is also available from the project page. This tool can test multiple versions of the tool against multiple repositories which is pretty cool when checking for regressions. There are currently 48 tests although tests can be easily added or removed as needed. It can optionally display the results to the screen, but by default it records them in a directory where a basic consistency check is performed to detect differences in output (for the same repository) resulting from the use of different versions of the tool. This is not intended to be an all encompassing test suite or even a piece of production code, but rather a basic sanity check to make sure the key functions are working as expected.

Thanks again, Clive!

Keep the suggestions, reports and fixes coming!


Technorati Tag:

Friday Aug 01, 2008

NEW: Solaris Package Companion v0.8

Wow, has time passed since my last posting. I promise to do a quick update soon as a lot has been happening over the last six months! In the meantime, I wanted to tell you all about a new version of the Solaris Package Companion (version 0.8) that is now available.

For those not familiar with the tool, here is a brief overview:

   The Solaris Package Companion is a small Korn shell script that allows you to ask
   quite a number of interesting questions about the relationships between Solaris 
   metaclusters, clusters and packages as well as their respective dependencies. Very
   often, answers to these kinds of questions are essential for the construction of 
   minimized systems as well as more generally for OS golden images.

   The goal of the Solaris Package Companion, or SPC for short, is to do all of the 
   hard work so you don't have to. SPC will create a cache of important facts by mining
   information from the various packaging files and directories to allow you to quickly 
   and easily obtain answers to a variety of questions such as:

     \* What clusters or packages are contained in a given metacluster?
     \* What packages are contained in a given cluster?
     \* What metacluster or cluster contains a given package?
     \* On what other packages does a given package or cluster depend?
     \* Which packages depend on a given package?
     \* … and so on…

New to this release is a tree view display method that allows you to list the contents of metaclusters and clusters in a more eye-friendly tree-view. Thanks to Fredrich Maney for contributing the idea and code! Here are a few examples from the project page showing what this looks like:

To see what packages are included in a cluster, just use the "-t" option:

$ ./spc-v0.8.ksh -v -r ./myrepository -t SUNWCssh
   [C] SUNWCssh                  Secure Shell
      [P] SUNWsshcu                 SSH Common, (Usr)
      [P] SUNWsshdr                 SSH Server, (Root)
      [P] SUNWsshdu                 SSH Server, (Usr)
      [P] SUNWsshr                  SSH Client and utilities, (Root)
      [P] SUNWsshu                  SSH Client and utilities, (Usr)

To see what packages and clusters are included in a metacluster, just use the "-T" option:

$ ./spc-v0.8.ksh -v -r ./myrepository -T SUNWCmreq | head -10
[M] SUNWCmreq                 Minimal Core System Support
   [C] SUNWCfca                  Sun ISP Fibre Channel Device Drivers
      [P] SUNWqlc                   Qlogic ISP 2200/2202 Fibre Channel Device Driver
      [P] SUNWemlxs                 Emulex-Sun LightPulse Fibre Channel Adapter (FCA) driver (root)
   [C] SUNWCfct                  Sun Fibre Channel Transport Software
      [P] SUNWfcsm                  FCSM driver
      [P] SUNWfctl                  Sun Fibre Channel Transport layer
      [P] SUNWfcp                   Sun FCP SCSI Device Driver
      [P] SUNWfcip                  Sun FCIP IP/ARP over FibreChannel Device Driver
   [C] SUNWCfmd                  Fault Management Daemon and Utilities

I would also like to thank Peter Pickford for sharing a fix for a bug that resulted in the tool not properly recording all dependencies under certain circumstances. Thank you! While I was at it, I also took a little time to clean up the code a bit.

You can find more information, examples and the source code on the project page.

Keep the suggestions, reports and fixes coming!


Technorati Tag:

Thursday Jan 31, 2008

HEADSUP: Solaris 10 Security Best Practices

Just a quick heads-up note to say that the official Sun location for the Solaris 10 security recommendations documents has changed. While you can still get to the content from the OpenSolaris Security Community Library page, the new location is on

The recommendations documents have been bundled into an archive so that they can be more easily downloaded in a single step. The individual documents are still available and can be downloaded at:

Monday Jan 07, 2008

Top 5 Solaris 10 Security Features You Should Be Using

Inspired by Solaris 10 winning a spot on the InfoWorld 2008 Technology of the Year Award list, I decided to write up a list of my own. I hope you forgive this little bit of cheerleading, but I just could not help myself...

The Top 5 Solaris 10 Security Features You Should Be Using!

This list is intended to highlight five security controls found in the Solaris 10 OS that will offer the most direct and immediate value to you and your organization. I stopped the list at five to simply provide a representative list, but you can see from this deep dive presentation that Solaris has a lot more to offer. At any rate, let's get on with the list... (drum roll please)...

5. Auditing.

Yes, 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. Solaris Auditing is a great facility to figure out what is happening on your systems. As a kernel-based facility, it can see and record everything that is happening - which is absolutely critical for organizations concerned with compliance. Martin has published a nice audit configuration to address the security requirements for the payment card industry. We also have a whitepaper that discusses how Solaris as a whole stacks up in this area, but I digress... Moving on.

4. Privileges.

You are likely using privileges without even knowing it, and that is a good thing. Solaris has implemented the principle of least privilege across many of the default set-uid binaries and system services. By default, many services are granted only those privileges they need (or simply drop those that they do not need). That said, why stop there? This Sun BluePrint describes how to integrate privileges into third-party or even your own applications. Further, for those doing software development, this paper talks about how to integrate privileges directly into your code to bracket your use of privileges - further limiting when your code will run with privileges. Don't know what privileges you need? Check out our privilege debugger - it will show you the way. By running with only those privileges that you need, your window of exposure is significantly reduced - and we can all agree that is a good thing.

3. Role-based Access Control.

Need to limit access to administrative functions? Do you occasionally need to perform privileged operations? Role-based Access Control or RBAC is the answer. Originally integrated in Solaris 8, RBAC has become increasingly more integrated with the rest of the operating system. For example, if you want to allow your operators to restart but not change system services, RBAC can help. Bart has developed a very nice tour of RBAC for those new to the technology. For those wanting something a little more advanced, you can use RBAC to implement a two-person (or four-eyes) access control scenario. Regardless, of whether you just want to want to just delegate root access or you want to implement a sophisticated access control policy, RBAC can scale to meet your needs.

2. Zones.

You knew I would be getting to zones, right? 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. Zones operate with fewer privileges than their global zone counterpart - making privilege-oriented attacks far more difficult to achieve. More than that, the core OS binaries, libraries and kernel modules are all effectively immutable in the default configuration since they are provided using read-only loopback mounts from the global zone. What does this mean? Simply put, you can't change them. This is a huge win for security, for change control, for IT governance - you name it. You can give access to applications to do their work in a safe environment without risking changes to the underlying OS. That said, if you need to make changes, Solaris is flexible enough to accommodate. You can add devices, file systems, network interfaces, even privileges to zones. You can enforce various resource controls on zones to prevent them from using an unfair share of Solaris resources. What's more - you can personalize your zone with its own hardening configuration, naming and authentication services, audit policy, and much more. You can even do some very interesting things with cooperating zones. Zones offer such compelling security capabilities that they (along with auditing, privileges and RBAC) serve as a cornerstone of Solaris Trusted Extensions, Sun's multi-level operating system that implements mandatory access control.

1. Network Secure by Default.

Last, but certainly not least on this list is Secure by Default or SBD. SBD was introduced in Solaris 10 11/06 as a means of significantly reducing the network-visible attack surface of the Solaris OS - particularly for out of box configurations. Huh? It means that when SBD is selected at installation time, the only Solaris OS service that will be exposed on the network is Secure Shell (rather than a traditionally long list of services that may or may not be used in your deployed environment). SBD can be selected at install time (for initial installs) or post-installation time (for upgrades and when you just want to enable it later). It will either turn off services that were deemed non-critical or set required services to a local-only state where they will respond only to requests coming from the local machine itself. This allows you to start from a more secure default configuration and enable only those services that you actually need. SBD can be configured in the global zone or in any number of non-global zones (since they can have their own configurations). For those wanting a bit more in terms of customization (for which services they want to disable, enable, set local-only, etc.), you may want to consider using the Solaris Security Toolkit where you can set policies against which the system configuration can be assessed or set. Regardless of which tool you choose, you can now more easily lock down your Solaris 10 deployments.

I hope you enjoyed this look at the Top 5 Solaris 10 Security Features You Should Be Using. If you want to learn more about what capabilities Solaris 10 has to offer, you have a wealth of options to help you get up to speed:

Until next time...


Technorati Tag:

Friday Jan 04, 2008

UPDATED: Solaris - Now With More Fuzz

Every six months or so, I try to do a run of my fuzz tests against the Solaris OS. The first test was conducted a year ago with build 42 followed by a test during our summer break on build 68 of Nevada. It should come as no shock then that I conducted another test during the winter break on build 80.

The tools and methodology are the same (although there are still some kinks to be worked out to make it fully automated), but for those who have not read my earlier post, I will summarize. The tests were conducted on a fresh installation of Nevada build 80 built with the SUNWXCall (Entire + OEM) installation cluster. A sparse-root, non-global zone (called "fuzz") was created for the tests and the software was loaded into the zone. Next, the names of all of the ELF binaries were collected, using the make-exec-list script run from within in the non-global zone. Next, the make-fuzz-tests script was run to generate the 36 different fuzz files to be used as input for each binary tested. Lastly, the test was kicked off using the exec-fuzz-tests script. The script pretty much runs unattended except when I need to kill off runaway processes. I still need to add some code to kill off anything started at the end of each test so you do not end up with tons of extra processes running and consuming memory.

At any rate, the test run completed and I have posted my results in Bugster and the bugs are also available in the OpenSolaris Bug Database Search using the keyword fuzz. The programs impacted can be viewed using this query.

While I tend to do this kind of work for fun as a holiday distraction, it does have real benefit. Programs that fail during a fuzz test (usually core dumping although a runaway or two have also been found) fail due to unvalidated input that leads to a buffer overflow or arithmetic exception of some kind. Input validation is not to be taken lightly and should be performed by every program and service. In fact, on the CERT Top 10 Secure Coding Practices list, validate input is item #1 and with good reason.

Take care,


Technorati Tag:


This area of cyberspace is dedicated the goal of raising cybersecurity awareness. This blog will discuss cybersecurity risks, trends, news and best practices with a focus on improving mission assurance.


« August 2016