The Secure by Default project is now integrated into Solaris Nevada build 42. This project is all about installing Solaris in a more secure configuration, right out of the box. It's something our customers have been requesting for a long time.

In this case, the more secure configuration is one where there are no network services accepting input from remote clients. Why is that more secure? Because network services are implemented by software, and software - no matter how carefully it is designed - sometimes contains serious bugs. Every service listening to the network presents an attacker with one more opportunity to exploit any vulnerabilities that code might contain.

We made one exception to this "no network services" rule for Secure Shell or ssh. You still need some way to administer the system when the console is unusable, either because no one is locally present or because of a catastophic error. For that purpose, ssh is a more secure choice than rlogin, telnet, or similar services.

Secure by Default uses the Solaris Service Management Facility (SMF) to control network services. Some are disabled completely, while others are configured using SMF properties to accept input only from clients on the local system. Starting from this secure baseline, the administrator can use SMF to enable any additional services he actually wants to have listening to the network.

Now that Secure by Default is available as part of Solaris Express, people have been asking questions about the implementation details. To help answer them, I've created an OpenSolaris project page. If you're interested in exactly which SMF services and properties are affected by Secure by Default, take a look at the design specification found there. For a tutorial introduction, you may also want to check out Glenn Brunette's blog entry about Secure by Default.

I spent an enjoyable Father's Day today, pretty much following the script for a sterotypical Sunday afternoon in suburban America. I watched the Champ Car Grand Prix of Portland on TV and then barbecued spare ribs and asparagus for dinner.

While waiting for dinner to finish cooking, I started thinking about the times I'd enjoyed around the barbecue with my dad, who passed away less than six months after my two-year-old son was born. It suddenly struck me that the motion I used to turn over the asparagus mimicked the way he used to do it.

It got me thinking about what I would teach my son about cooking with fire when he's older. Will we start with charcoal to master the basics before switching to gas, just like people who learn to drive a stick shift even if they generally drive an automatic? Or will that be hopelessly old-fashioned? ("C'mon, Dad, that's like entering text with a keyboard.") In the end, it doesn't really matter. I just hope that years from now, he looks back with fond memories of the experience and finds something to pass along to his son.

In honor of the release of OpenSolaris today, lots of Sun engineers have written blog entries about various things they implemented or fixed in Solaris. Check them out; there's lots of great technical content and some fascinating stories. Instead of writing about one specific part of the source code, I decided to describe something I did that involved small changes in dozens of source files.

About eighteen months ago, I changed the build process to make use of a new lint option that is designed to detect coding practices that could lead to security vulnerabilities. This checking is controlled by the -errsecurity option on the lint command line, which runs the security checks at one of three levels.

Changing the makefiles to add an option to each lint command line was trivial. All I had to do was add the following lines to usr/src/Makefile.master:

ALWAYS_LINT_DEFS +=   -errsecurity=$(SECLEVEL)
ALWAYS_LINT_DEFS +=   -erroff=E_SEC_CREAT_WITHOUT_EXCL
ALWAYS_LINT_DEFS +=   -erroff=E_SEC_FORBIDDEN_WARN_CREAT

SECLEVEL=     core

With these lines in Makefile.master, a simple make lint in any source directory will run lint with -errsecurity=core. To run the security checks at one of the other levels, just override the SECLEVEL variable on the command line; e.g., make lint SECLEVEL=standard.

Then the real work began. Adding this option caused lint to produce about 500 additional warnings. I needed to fix all of these before integrating my change to Makefile.master because we require the Solaris source to be lint-clean.¹ Interestingly, almost all of the problems detected by lint resulted in one of just three error messages. Since newly written code is likely to produce many of the same warnings, I thought it would be useful to describe what these messages mean and how to fix them.

1. variable format specifier to printf()

2. format argument to sprintf() contains an unbounded string specifier

3. format argument to scanf() contains an unbounded string specifier

/*
 *      Macros to produce a quoted string containing the value of a
 *      preprocessor macro. For example, if SIZE is defined to be 256,
 *      VAL2STR(SIZE) is "256". This is used to construct format
 *      strings for scanf-family functions below.
 */
#define QUOTE(x)        #x
#define VAL2STR(x)      QUOTE(x)

char ctd[MAXNAMELEN + 1];

while (fscanf(fp, "%" VAL2STR(MAXNAMELEN) "s", ctd) == 1) {
	...
}

1. To be more precise, a top-down build runs lint on only part of the source code, and we require that subset of the code to remain lint-clean. There is plenty of code that hasn't been made lint-clean yet, either because the code is old or because it comes from an external source and we don't want to diverge from the outside version. See usr/src/Makefile.lint to find out which source directories are linted.

Technorati Tag: OpenSolaris
Technorati Tag: Solaris

Blogging has become very popular lately at Sun, especially in conjunction with today's launch of OpenSolaris. Looks like it's time for me to dive in as well.

So who am I? I'm an architect in the Solaris group, where I work on OS security features. For my first few years at Sun, I worked on Trusted Solaris, Sun's multi-level secure version of Solaris, and helped lead the effort to migrate some of its features into mainstream Solaris.

Before coming to Sun, I worked as an engineer or manager in UNIX kernel groups at several other companies. I can honestly say that the Solaris organization at Sun is the most impressive group of engineers I've ever worked with; it's a privilege to be a part of that team. I'm excited by the idea that through these blogs we can give the rest of the world a little more insight into what we do here and why it's such a special place to be.