Glenn Brunette's Security Weblog


Solaris Secure by Default - Part 3

Wednesday Jul 19, 2006



Before I begin, I would like to point everyone to a posting by Scott Rotondo, one of the architects behind the Secure by Default project. Check it out and let him know what you think of this new Solaris enhancement!

Today, SBD is an all or nothing proposition - it is either enabled or disabled using the new netservices(1M) command. For many organizations, this is not enough. Very often, they must configure their systems such that some services are "off" or in a "local only" mode while others must be enabled or "open" to support a business or technical requirement. It is important therefore to be able to understand exactly what SBD is doing so that you can better tune the security configuration of your systems based on your specific needs and requirements. As we have noted previously, a SBD configuration is created by (1) disabling services or (2) adjusting service properties to put the service into a "local only" mode.

The enabling and disabling of services is a trivial matter. Simply using the svcadm command with the enable or disable action to adjust the services that interest you. Since this is a very easy matter, this will not be the focus of this posting. For the third and final (for now) installment of Getting to Know - Solaris Secure by Default) (SBD), I would like to focus specifically on those services that are not disabled by default but instead are configured to accept only local connections (originating with the system itself).

Taking a look at the Secure by Default design document, you see that the list of services impacted are (expressed as FMRIs):

  • svc:/network/rpc/bind
  • svc:/system/system-log
  • svc:/network/smtp:sendmail
  • svc:/system/webconsole:console
  • svc:/application/management/wbem
  • svc:/application/x11/x11-server
  • svc:/application/graphical-login/cde-login
  • svc:/network/rpc/cde-ttdbserver:tcp
  • svc:/network/rpc/cde-calendar-manager
  • svc:/application/print/rfc1179:default
SMF property is used to set the Secure by Default behavior or to return the service to its traditional operating mode. In the table below, the property values set when operating in a SBD mode are presented in bold.

Solaris SBD SMF Properties and Values
ServiceFMRIPropertyValues
rpcbindsvc:/network/rpc/bindconfig/local_onlytrue, false
syslogsvc:/system/system-logconfig/log_from_remotetrue, false
sendmailsvc:/network/smtp:sendmailconfig/local_onlytrue, false
smcwebserversvc:/system/webconsole:consoleoptions/tcp_listentrue, false
wbemsvc:/application/management/wbemoptions/tcp_listentrue, false
X11svc:/application/x11/x11-serveroptions/tcp_listentrue, false
CDEsvc:/application/graphical-login/cde-logindtlogin/args[null], -udpPort 0
ToolTalksvc:/network/rpc/cde-ttdbserver:tcpprototcp, ticotsord
Calendarsvc:/network/rpc/cde-calendar-managerprototcp, ticlts
BSD Printingsvc:/application/print/rfc1179:defaultbind_addr[null], localhost

Pretty easy, right? So, let's say you were running in a SBD mode (after having run netservices limited) and you find that you want to be able to receive syslog messages from another host. All you would need to do is: 

# svccfg -s system-log setprop config/log_from_remote = true
# svcadm refresh system-log

If you wanted this change to take effect immediately, you should also run: 

# svcadm restart system-log

Another cool thing about this is that communication is prevented between non-global zones and the global zone since the service is either bound to localhost or simply will not accept external connections: 

# ifconfig hme0
hme0: flags=1000843 mtu 1500 index 2
        inet 192.168.1.250 netmask ffffff00 broadcast 192.168.1.255
        ether 0:0:0:0:0:0

# rpcinfo -p 192.168.1.250
   program vers proto   port  service
    100000    4   tcp    111  rpcbind
    100000    3   tcp    111  rpcbind
    100000    2   tcp    111  rpcbind
    100000    4   udp    111  rpcbind
    100000    3   udp    111  rpcbind
    100000    2   udp    111  rpcbind

# zlogin time ifconfig hme0:2
hme0:2: flags=1000843 mtu 1500 index 2
        inet 192.168.1.240 netmask ffffff00 broadcast 192.168.1.255

# zlogin time rpcinfo -p 192.168.1.250
rpcinfo: can't contact portmapper: RPC: Authentication error; why = Failed (unspecified error)

Pretty neat! Well, that's all for this installment. Please let me know what you think or if you have any questions! We love to get feedback and your input is very important to us!

Take care,

Glenn

References: Part 1 of 3 Part 2 of 3

Technorati Tag:

[2] Comments

Share and Enjoy! reddit stumbleupon
Posted at 02:18PM Jul 19, 2006 by gbrunett in Solaris 10 Security Tags:
Comments:

How is the "config/local_only" property implemented? What does it do behind the scenes, how does it manipulate configuration files? Probably the most important question of all: how are these changes kept in sync with the package database? And what happens during an upgrade? Are the files in the "config/local_only" property registered as type "e" (editable) in /var/sadm/install/contents? Is there any documentation that details which files are guaranteed not to be overwritten or modified during an upgrade?

Posted by ux-admin on July 21, 2006 at 03:24 AM EDT #

ux-admin,

The config/local_only (and similar SBD properties) are handled in different ways for different services. For example, the options/tcp_listen property for x11-server is queried by /usr/X11/bin/Xserver. The value of the property is used to determine whether the -nolisten tcp argument will be applied to the X11 server being started. rpcbind on the other hand checks the config/local_only property itself in order to determine how to behave.

The SMF properties do not change existing SMF manifests or configuration files. They SMF properties are sometimes queried by SMF methods (as noted above) or by services directly in order to determine how a service is to act.

As SMF properties are not filesystem objects, they have no relationship to the package database. Therefore, you will find no mention of them in the contents file.

On upgrade or patching, the SMF properties set by administrators or by SBD will not be changed (if you see otherwise it is likely a bug). Note that SBD will not be implemented when upgrading to Solaris 10 / OpenSolaris / Nevada. If you choose to upgrade an existing system, you will need to use the netservices(1M) command to apply the SBD profile.

Let me know if this helps,

Glenn

Posted by Glenn Brunette on July 23, 2006 at 09:36 AM EDT #

Post a Comment:
Comments are closed for this entry.