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. (
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.
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`
flags = PRIV_AWARE
As I noted: increasingly secure.)