Flag day: Secure by Default
Date: Thu, 01 Jun 2006 17:01:19 -0700
From: Scott Rotondo <scott dot rotondo at sun dot com>
To: onnv-gate at onnv dot eng dot sun dot com, on-all at eng dot sun dot com
Subject: Flag day: Secure by Default
Today's integration of
PSARC 2004/368 Secure by Default
introduces a change for anyone who does an initial install of Solaris
Nevada. There is no effect by default on those who upgrade or bfu
existing systems.
Any custom install images containing these bits, and all official
install images beginning with snv_42, will be affected. See the "Notes
for SWAN Systems" section below for some common situations that may
arise for systems installed from these images.
Description
~-----------
On newly installed systems, all network services (except for ssh) that
were previously enabled by default are now either disabled or
constrained to respond to local requests only. This change minimizes
the attack surface for an installed system and provides a base for
customers to enable only the services they require.
All of the affected services are controlled by the Service Management
Framework (SMF). Any individual service can be enabled using the normal
svcadm(1M) and svccfg(1M) commands.
Disabling network services can also be achieved manually by running
# netservices limited
This can be used on upgraded systems, where no changes are made by
default, or to re-establish the hardened state after enabling
individual services. Similarly, default services can be enabled as they
were in previous Solaris releases by running
# netservices open
There are two situations where you may see services listening to the
network even when running in the "netservices limited" state. First,
there are a few non-ON services, primarily for Gnome, that still
require modifications to limit them to local requests. These changes
will be included in an upcoming build. Second, in the SWAN environment
there are services that are typically enabled to support NIS and NFS.
Although these services are not enabled by default, they will be
running on most in-house systems due to administrative configuration.
Notes for SWAN Systems
~----------------------
If you run a system in the limited networking state, you may encounter
one or more of the following situations:
1. NFS file locking
Mounting or exporting an NFS filesystem automatically starts the lockd
and statd daemons to support file locking. However, these daemons rely
on rpcbind, which may be running in the local-only configuration. We
are currently fixing two bugs that will address this problem by
automatically enabling network access to rpcbind when lockd and statd
are started.
6432967 rpcbind must listen to the network if NFS is in use
6432964 rpcbind should not require restart to begin listening to the network
We expect to putback fixes to these bugs in the next few days. In the
meantime, NFS clients and servers (essentially, all systems on SWAN)
should configure rpcbind to listen to the network as follows.
# svccfg -s rpc/bind setprop config/local_only = false
# svcadm refresh rpc/bind
# svcadm restart rpc/bind
Note that restarting rpcbind will cause all RPC services to be stopped
and restarted.
2. Enabling sendmail
If you receive email on your local system, you will need to enable
sendmail to listen to the network as follows.
# svccfg -s sendmail setprop config/local_only = false
# svcadm refresh sendmail
# svcadm restart sendmail
3. Allowing remote X clients
If you wish to allow X clients from other systems to work on your
display, you will need to enable the X server to listen to the network
as follows.
# svccfg -s x11-server setprop options/tcp_listen = true
[Restart the X server.]
Note that this is not necessary if you use X11 forwarding via
ssh -X.
Contacting Us
~-------------
Bug reports for Secure by Default may be filed under
solaris/utility/smf. If you encounter problems or have questions,
please contact the project team at sbd-core at sun dot com dot