smf(5) design admissions

In a Usenet thread on comp.unix.solaris and an earlier comment series in the "Comparing Linux to System VR4" on Slashdot last week, some valid smf(5) criticisms have been raised. I thought I would reply to them here, and acknowledge the impact on some practices.

The strongest recent critic has been Tim Hogard, and I hope he doesn't mind if I collect his concerns to structure my response. Mr Hogard is a member of the class of exceptional administrators that have designed their systems' behaviours (by removing unneeded software and writing precise configurations for what remains, among other good practices). I've always known that this group of experts would be most directly impacted by the changes smf(5) brings, and have tried to listen carefully to their concerns and modify the implementation to accommodate them. (Such people exist within Sun and in the Beta and Express communities.)

"On my system the binary file contains the last time when the service started. That means a file in /etc gets written with every boot." There are actually two binary files that contain the set of information the facility acts on:

• /etc/svc/repository.db, which is persistent and contains the service definitions, dependencies, and so on, and
• /etc/svc/volatile/svc_nonpersist.db, which is non-persistent and contains service execution information, such as process IDs, contract IDs, and stae transition times.

(/etc/svc/volatile is a tmpfs filesystem mounted by the kernel prior to startup being turned over to the progeny of init(1M). Its contents do not persist across OS instantiations.)

I believe the concern here is that /etc/svc/repository.db change detection cannot be managed using fingerprints. This is in fact a bug:

6221934 *svc.configd* must respect repository filesystem metadata

as the current implementation does an idempotent test transaction to verify writeablity (in addition to other integrity checks). In the meanwhile, one can indirectly use a hash- or checksum-based fingerprint using the output of the archive subcommand to svccfg(1M), which dumps the repository as an XML document. An example using cksum(1):

13 $ svccfg archive > /tmp/a
14 $ svcadm disable manifest-import
15 $ svccfg archive > /tmp/b
16 $ svcadm enable manifest-import
17 $ svccfg archive > /tmp/c
18 $ cksum /tmp/a /tmp/b /tmp/c
1649351107      205437  /tmp/a
2659093841      205438  /tmp/b
1649351107      205437  /tmp/c
19 $ # use diff to examine repository differences globally...

But we'll get that bug fixed shortly.

"I've found some very interesting things to do to the new system that can mess up a box in a way that the current tool set won't even let you see what is wrong. It appears to be a script kiddies back door dream." I am less certain I understood this point. There are no hidden services in the repository, although you can certainly corrupt the repository deliberately. (Separate backup repositories are made automatically at stages of boot; a recovery utility is provided in /lib/svc/bin.) Because each process is a member of a process contract owned ultimately by svc.startd(1M), you can use svcs -p if you trust the repository and ptree -c if you don't. (If you don't trust the kernel any longer, then we're onto intrusion containment and system reinstallation from trusted media.)

"And yes I'm saying complexity is bad and we should stick with what works (and it isn't DOS)." Unfortunately, what worked once no longer works given today's requirements. The Predictive Self-Healing initiative at Sun and equivalents elsewhere are responses to a change in availability requirements: both hardware and software components have the potential for failure, and the operating system needs to acknowledge this outcome and provide abstractions and capabilities to manage its implications. It's my belief that smf(5) introduces a minimal amount of complexity in exchange for new and meaningful descriptive objects and, in fact, the simplification of some previously difficult operations.

This reply hasn't explained why there's a transactional database (which, as an implementation detail, is currently SQLite), or why hierarchical restart is a different problem than parallel startup, or why we converted the current system to use the facility rather than providing only the framework. I'm happy to expand on any of these, or the points above.

(2005-01-26 14:08:01.0) Permalink Comments [1]

Fiddling with del.icio.us

I've started moving bookmarks onto del.icio.us, the slick social bookmarking service. Enough real work beckons that I'm resisting whipping up some Perl to glue Netscape::Bookmarks and Net::Delicious together, so for now I'm manually posting important or new bookmarks.

If you're a del.icio.us user, and want to help build a shared link set for smf(5), please consider using "solaris smf" in your tags. The current list is incomplete.

(2005-01-25 22:45:51.0) Permalink

Recovery from another hiatus; an smf(5) one-liner

I was out with sick children last week and have been engaged in a form of mental wrestling learning the Dvorak keyboard for the past two—both impediments to concentration, and thus to smooth blogging. Everybody is on the mend; evening wakeups are on the decline. I no longer want to hurl my keyboard across the office; my brain is remapping favourite commands and key sequences. (slrn and ls, which use the fourth and fifth fingers of the right hand (or only the fifth), feel very awkward still.)

There were some interesting smf(5)-related asides in some Slashdot discussions last week. One requires a separate, detailed reply. The other—a request for a single command that hardens your Solaris system—can be answered briefly. There are two answers: one a flip one-liner, one responsible.

The glib smf(5) one-liner answer is:

# svccfg apply /var/svc/profile/generic_limited_net.xml

which applies the "limited networking" profile to your system. This profile deactivates about three dozen services that are active in the traditional install case, including all passwords-in-the-clear login services. There are still RPC and likely other services active on the system that serious system auditors will want to examine. (The limited networking profile was written by members of the Solaris Security Technology group and will be present in the initial release of Solaris 10. And we're now working to make that initial install initially and increasingly secure.)

The more responsible answer is to point out that system hardening requires both minimization and reconfiguration (beyond service deactivation) and that there is a productized distillation of security practices for Solaris in the form of the Solaris Security Toolkit. Although its use might exceed a one line constraint, the toolkit makes fungible years of Solaris hardening experience.

(I'll refrain from describing how the now-integrated IPFilter or tcpwrapper support can reduce the exposure of some of the remaining services. But I will point out that the combination of the least privileges feature and the smf(5) service description's ability to define the appropriate privileges for a service lead to an rpcbind(1M) that cannot successfully call exec(2) (among other things):

# ppriv `pgrep -z global rpcbind`
100220: /usr/sbin/rpcbind
flags = PRIV_AWARE
        E: basic,!file_link_any,net_privaddr,!proc_exec,!proc_info,!proc_session,sys_nfs
        I: basic,!file_link_any,!proc_exec,!proc_fork,!proc_info,!proc_session
        P: basic,!file_link_any,net_privaddr,!proc_exec,!proc_info,!proc_session,sys_nfs
        L: basic,!file_link_any,!proc_exec,!proc_fork,!proc_info,!proc_session

As I noted: increasingly secure.)

(2005-01-24 23:20:34.0) Permalink Comments [2]