Friday July 14, 2006 
Today's Page Hits: 21
Friday July 14, 2006 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.
Sunday June 19, 2005 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.
Tuesday June 14, 2005 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.1 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()
Format strings used with the printf family of functions
should be fixed string literals. If they are variables derived from
user input,
several attacks
are possible, particularly using the %n format specifier.
Some techniques for fixing code like this:
- Instead of printf(str) use printf("%s", str) or puts(str).
- For functions that are wrappers around printf for debugging, error messages, etc., be sure the function is marked with the /*PRINTFLIKE*/ lint directive. This allows lint to verify that the arguments to the function match the format string, and it suppresses the warning when the variable format string is passed to vprintf.
- Note that lint treats the strings returned from gettext and dgettext as constants, so it's
OK to use them in place of string literals.
- If you must use a variable format string (e.g. to select at
runtime between two fixed format strings), declare the variable as a const char * to suppress the
lint warning.
2. format argument to sprintf() contains an unbounded string specifier
A format string that contains %s can write an unlimited
amount of output, possibly overflowing the fixed-size buffer passed to
sprintf. Two simple techniques to fix this are:
- Use snprintf instead of sprintf. The size argument places an upper bound on the number of characters that will be written to the buffer.
- Change the format string to limit the number of characters
written, e.g. %10s to
write at most 10 characters. This is also the reason lint does not
complain about sprintf calls that use fixed-size formats like %d.
3. format argument to scanf() contains an unbounded string specifier
Just as it does in the case
above, a %s
in a scanf format string can write an unlimited number of characters
and possibly overflow the buffer supplied. For scanf, however, only one
fix is available:
- Change the format string to limit the number of characters. Important: The size given in the format string does not include the trailing null character, so a format of %10s requres an 11-byte buffer.
/*
* 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
Ab Initio
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.