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 (127.0.0.1) 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

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.

-Dave

Permalink | Comments [2]