Top 5 Security Features in Solaris 10

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.