SPOTD: In a Secure By Default world, is the Solaris Security Toolkit still relevant?

Following the integration of the Secure By Default (SBD) work into Nevada build 42 and, subsequently, Solaris Express and Solaris 10 11/06, some colleagues have been asking me whether the Solaris Security Toolkit (SST, aka JASS) still has a useful part to play. My answer is "definitely", and here's why.

SBD acts to either disable services completely, or to force them to only bind listeners to a loopback ( interface. SST is equally capable when it comes to disabling services, however the "bind only to loopback" capability is currently beyond its capability.

By contrast, there's a whole bunch of things which SST can do that SBD doesn't, today. These include:

  • setting nscd cache timeouts to zero
  • restricting the use of cron and at
  • enforcing the use of particular password encryption algorithms and requiring the use of what are considered to be "strong" passwords
  • setting warning banners on login services
  • randomising packet sequence numbers (as per RFC 1948)
  • controlling where core files are put short, where SBD hardens a system by disabling or constraining service listeners, SST further hardens a system by finessing the ways in which services and the underlying OS capabilities (network stack, etc) are configured.

There's a few design reasons why SBD doesn't do all the things that SST does - such as enabling packet sequence number randomisation by setting TCP_STRONG_ISS to 2 in /etc/default/inetinit and setting nscd timeouts to 0. As SST isn't run on a system by default, whereas SBD is the default configuration on Nevada and Solaris Express (although not on Solaris 10, for reasons of backward compatibility), SST can "get away with" doing some things that SBD can't.

So, how can you best go about using the two capabilities together?

First, ensure that once you've installed SST, you also patch it with 122608-03 or later, so that it understands SBD. Next, depending on what services you intend to present from your system, you can set SBD to netservices limited; about the only situation I can think of when you wouldn't necessarily want to use SBD everywhere is when you want to present something which has a lot of dependencies on Solaris services, such as Sun Ray services. If you're building a SNAP server on Trusted Extensions, for instance, while it's sensible to use netservices limited on the non-global zones handling each label, it's easier to leave the global zone (aka Trusted Path) at netservices open, and lock it down with SST.

For a service with less complex dependencies, it's sensible to use netservices limited, open up whatever dependent services are required using SMF, and then apply SST. In the event that the system needs to be reconfigured, make sure that SST and SBD operations are "nested" correctly; as SST is the last thing applied it needs to be the first thing undone with jass-execute -u, and then SMF can be used to change the SBD profile before re-hardening with a suitably-modified SST .driver.



Is the setting of nscd cache timeouts to zero always a good idea? If you are using a network based name-service like LDAP then not caching any results can cause a substantial increase in query load and latency, especially in large environments. It isn't clear to me that the trade off is always worth it.

Posted by William Hathaway on May 21, 2007 at 02:49 AM PDT #

One other thing is that SBD is not able to audit itself today. That is, you do not have an easy way to validate that a system is running in compliance with the SBD policy. Conversely, the Solaris Security Toolkit can be used in both hardening and audit modes whereby a system could be checked for compliance against a specific profile (driver) at any point in time and even hardened again to reinforce compliance.

Posted by Glenn Brunette on May 29, 2007 at 12:23 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

This blog provides security vulnerability fix notifications relevant to third party software components distributed and supported as part of Oracle Products.
Summarized version of this blog is available as a mapping of CVEs and solutions.


« February 2016