Chapter 8. Security Improvements

To avoid locking the barn door after the horse has bolted, it's good to be aware that there is a lock available for you to use in the first place. Take a moment to peruse the assortment of new locks available in Solaris 11.

Alongside some miscellaneous changes, the major deadbolts covered in this chapter are:

• Auditing changes

• Immutable zones

• Sudo

• Encrypted ZFS

Keeping the horse in the barn

There is an assortment of new security-related features in Solaris 11, in very disparate areas. I would recommend that you glance at all the items in this chapter. Even if you don't use them right away, they may prove useful to you at some point in the future.

Mandatory auditing

Auditing is now enabled by default in Solaris 11. Previously, enabling auditing required running the bsmconv tool, and then rebooting. Now, however, it is an SMF service, svc://system/auditd:default, and can be enabled and disabled without rebooting. Additional good news is that there have been some internal performance optimizations for auditing as well.

Audit changes now must be done only through auditconfig. It is no longer possible to edit the old plaintext file /etc/security/audit_startup.

As usual for the audit daemon, logs are stored by default in the /var/audit directory. It is possible for each zone to have its own audit logs, or for the global zone to be responsible for everything. See the Audit policies section of this chapter for more details.

Auditing basics

For those people who have not previously had to deal with auditing under Solaris, here is a brief overview. Audit logging allows you to record various events that happen to the system. Such events can include...

Immutable zones

Full configuration details for immutable zones are covered in Chapter 7, Zones in Solaris 11, but it is worth mentioning the rationale for them here.

To have an almost hack-proof system, it is very effective to take away write access from it as much as possible. If you are willing to run your services in a zone, it is possible to configure that zone as an immutable zone. This allows you to render filesystems and even service configurations as immutable (that is, non-writable).

Most remote attacks succeed by eventually writing corrupted data to the filesystem, and then taking more control from there. If they cannot write to the filesystem, many avenues of attack are closed. Furthermore, if they cannot deface the site, or store their own files, the incentive for taking over the system may also have been removed.

There are varying levels of immutability possible. If your services will not run in a fully read-only zone, it is possible to allow access to /var, and a few other filesystems...

ProFTPd is the new FTP server

For a very long time, the FTP server bundled with Solaris has been based on the WU-FTPd program. In Solaris 11, this has been changed to ProFTPd.

In addition to being more current, easier to configure, and more flexible, ProFTPd has the advantage of being more secure. The ProFTPd team takes security very seriously; it has a mailing list, <[e-mail]>, dedicated to resolving any security issues in a timely manner.

The best practice for setting up anonymous FTP is to create a chroot directory. In older FTP daemons, this required setting up a special directory with copies of standard libraries. Some people may have avoided doing so due do this complexity.

ProFTPd eliminates this requirement, thus encouraging better security practices.

In addition to improvements for anonymous FTP, ProFTPd gives the ability to force all users to be "chrooted" on login. This means that FTP users will not be able to change the directory (cd) outside their home directory...

Sudo privileged access tool

The sudo tool (aka "su do") has long been a favorite of Unix admins (including MacOS), but prior to now, had to be installed from third parties on Solaris. Now in Solaris 11, it comes as part of the base OS package.

For those people who have somehow never used it before—don't worry, it's quite simple to use. The user interface is a little like Solaris pfexec. In the simplest case, you simply insert the word sudo in front of any command you wish to run with root privileges. For example:

sudo snoop

If you have not run the sudo command in the last few minutes, it will ask for your password (not the root password, but your own). It will then cache a successful entry so you do not have to enter your password every time.

It is also possible to run commands as other users quite easily. For example:

sudo -u apache apachectl restart

All this presupposes that there is an appropriate entry for your account in the sudoers config file.

Here are a collection of sample sudoers...

Direct root use now blocked by default

Previously, at manual system installation time, the OS installer would prompt you for a root password. Now, in addition to that, it will prompt you for the name/password of a user account intended to be the day-to-day account of the sysadmin.

If you follow along with this path, you will find out to your chagrin that you can no longer log in as root!

Attempts to log in as user root will be met with the complaint "Roles cannot log in directly". Instead, to run commands as root, you will be expected to use either sudo (with your own password) or su (with the root password).

If you find yourself in this situation and it does not sit well with you, don't panic! You can restore root to its full account status by editing the file /etc/user_attr and setting root's entry to be type=normal rather than type=role.

Fine-grained RBAC privileges

While Role-Based Access Control (RBAC) has been a part of Solaris for a long time now, Solaris 11 provides a few new knobs to play with. It is now possible to fine tune a user or process's ability to read or write a file, independently of each other. It is also possible to grant or take away the ability to have network access.

The specific new privileges are named, not surprisingly, file_read, file_write, and net_access.

It should be noted that net_access also affects the ability to use InterProcess Communication (IPC) mechanisms.

To take away a particular user's ability in one of these areas, use the usermod command as follows:

usermod -K defaultpriv=basic,!file_write targetuser

On-disk encryption

ZFS in Solaris 11 now also offers optional on-disk encryption. Some additional coverage of this is given in Chapter 6, ZFS – Now You Can't Ignore It!. The Solaris Cryptographic Framework libraries are used for encryption purposes, so ZFS will receive the benefit of any compatible crypto acceleration present on the system.

As an additional point of interest, the inherited nature of encrypted filesystems means that if a global zone creates a /zones filesystem, and then creates a zone with a zoneroots underneath, the zone will have the benefit of on-disk encryption without ever having direct access to the encryption key itself.

Warnings about encrypted ZFS filesystems

There are some gotchas to using a encrypted ZFS filesystem that should be carefully considered before using:

• Once you enable encryption on a ZFS filesystem, it cannot be turned off.

• Encryption will also be enabled on all subfilesystems, irrevocably.

• You cannot use zfs send/zfs receive for a non-encrypted ZFS destination...

Summary

Solaris 11 is serious about security. Its default configuration is to be secure, and allows you to tighten down the box even further with its pre-enabled auditing and available on-disk encryption. The ability to have fully read-only zones is possibly the ultimate secure server, if you don't count resorting to an appliance running purely out of ROM. Oracle has taken its enterprise mentality and applied it to Solaris security with great effectiveness.