 System Security in SolarisTM 10: Privileges and Zones in Perspective -- Part 2
Peter van der Weerd
In part one, I discussed
the improvements made to system security by using privileges as opposed to
using the su-command. It showed that priviliges can be
granted to processes, which overrules UIDs and
file-permissions. This shifts security control from UID to the process
level. Privileges in combination with RBAC give us a finer-grained security
model on Solaris 10. But that is not all; in combination with Solaris
Zones, they offer even more security by isolating application environments
and restricting file system access. After installing Solaris 10, you
already have one zone: the global zone. This global zone doesn't
really differ from Solaris without zones. The global zone is simply there,
up and running when you boot your machine. On top of this global zone, you
can install multiple local zones:
solx# zoneadm list -v
ID NAME STATUS PATH
0 global running /
A Solaris local zone is a lightweight virtual machine,
a technique to logically separate applications from one another. Typically,
a local zone has an IP address, based on a physical interface in the global
zone, usually shares certain file systems or directories with the global
zone, and has its own process tree. A local zone has its own console login,
can be installed, rebooted, halted, and uninstalled, without affecting any
other local zones or the global zone. Previously in Sys Admin, there have been articles
that concentrate on Solaris zones, so I will not dwell on that. If you are
new to Zones, "The Solaris 10 Zone Defense" by Kevin Wenchel
can be of help:
http://www.samag.com/documents/s=9494/sam0502b/0502b.htm
The problem we face is twofold. First, we do not want
to run Apache as root. A compromised httpd process would mean that the
culprit is root on our system. So, we make sure that all httpd daemons will run with the UID of a user called
"webservd" with UID 80. Also, we want to limit the privileges
that these httpd daemons have. We can use the
privilege sets to do so.
Second, what if we get hacked? We want to minimize the
damage. So, we are going to run our Web server in a Solaris Container,
safeguarding the global zone and other zones from damage done by the
intruder.
The Apache2 Directory Tree
Since we might want to run multiple Web servers in
different zones, we cannot use the standard location of the Apache2
configuration and documents environment. That is why we copy all relevant
files to a new directory that will later be used by the Web server zone
"web". For each new zone with a Web server with different
content, we would have to do the same. The first new zone will get its
Apache2 config and data files from the /apache directory:
solx# mkdir /apache
solx# mkdir /apache/config
solx# mkdir /apache/files
solx# mkdir /apache/files/run
solx# cp -R /etc/apache2/* /apache/config
solx# cp -R /var/apache2/* /apache/files
solx# mkdir /apache/logs
solx# mkdir /apache/run
Create the Zone
The name of the zone will be "web", and it
will have its root directory in the directory "/web":
solx# mkdir /web
solx# chmod 700 /web
solx# zonecfg -z web
apache: No such zone configured. Use 'create' to begin
configuring a new zone.
zonecfg:apache create
zonecfg:apache set zonepath=/web
zonecfg:apache set autoboot=true
zonecfg:apache add fs
zonecfg:apache:fs set dir=/etc/apache2
zonecfg:apache:fs set special=/apache/config
zonecfg:apache:fs set options=[ro,nodevices,nosuid,noexec]
zonecfg:apache:fs set type=lofs
zonecfg:apache:fs end
zonecfg:apache add fs
zonecfg:apache:fs set dir=/var/apache2
zonecfg:apache:fs set special=/apache/files
zonecfg:apache:fs set options=[ro,nodevices,nosuid,noexec]
zonecfg:apache:fs set type=lofs
zonecfg:apache:fs end
zonecfg:apache add fs
zonecfg:apache:fs set dir=/var/apache2/logs
zonecfg:apache:fs set special=/apache/logs
zonecfg:apache:fs set options=[rw,nodevices,nosuid,noexec]
zonecfg:apache:fs set type=lofs
zonecfg:apache:fs end
zonecfg:apache add fs
zonecfg:apache:fs set dir=/var/apache2/run
zonecfg:apache:fs set special=/apache/run
zonecfg:apache:fs set options=[rw,nodevices,nosuid,noexec]
zonecfg:apache:fs set type=lofs
zonecfg:apache:fs end
zonecfg:apache add net
zonecfg:apache:net set address=10.0.0.23
zonecfg:apache:net set physical=rtls0
zonecfg:apache:net end
zonecfg:apache verify
zonecfg:apache commit
zonecfg:apache exit
solx# zoneadm -z web install
Preparing to install zone apache.
Creating list of files to copy from the global zone.
Copying 2986 files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
preparing to initialize <923 packages on the zone.
The above may seem an endless list of settings, but
what really happens is that some mounts are created and an IP address is
configured. The attribute "dir" specifies the mountpoint from
within the local zone. The attribute "special" specifies the
directory that will be mounted from the global zone.
It is important to notice that the first two mounts
will be read-only. We do not want anybody to be able to change the
configuration from within the "web" zone. If changes are to be
made, this will have to be done from the global zone by accessing the
necessary files in /apache/config and
/apache/files.
Since the Web server should be able to write its PID
and logs, we have to mount /var/apache2/run and /var/apache2/logs
read-write.
The IP address is the address via which the Apache
zone will be accessible from the outside. The use of a Private Address may
seem confusing. But obviously, we are behind a firewall that will forward
http packets to the zone.
Now that we have installed the "web" zone,
we can boot it:
solx# zoneadm -z web boot
Log in to the Web console:
solx# zlogin -C web
This will log you into the console of the
"web" zone. Here, you will have to do some system
identification like:
- Setting the hostname
"web.not.com"
- Setting the time zone
- Setting the security policy (no Kerberos)
- Setting the name service
- Setting the root password
At the end, your zone will be rebooted automatically.
At the login prompt, type "~." to leave
the console because we have some things to do in the global zone again.
Configure httpd.conf
Apache2 comes with an example httpd.conf and a
standard httpd.conf. For ease of configuration, we copy the standard
configuration file to httpd.conf and change it:
solx# cd /apache/config
solx# cp httpd-std.conf httpd.conf
Next, we modify httpd.conf. Our DNS domainname is
"not.com.", so we adjust it. Look for "ServerName",
remove "#" and make sure it values "web.not.com.".
The default file where the Web server will write its
PID is different from our Web server, so we change it. Look for
"PidFile" and change the pathname into
"/var/apache2/run/httpd.pid":
The pathname of the LockFile is ok, but it is
commented out. Look for "LockFile" and uncomment the line that
points to "/var/apache2/logs/accept.lock" by removing
"#".
Since we will not run the httpd daemons as root user,
we change ownership of the two directories that will be mounted read-write:
solx# chown -R webservd:webservd /apache/run
solx# chown -R webservd:webservd /apache/logs
Set Properties for the apache2 Service
In a normal setup, apache2 will get started by root. A
total of 7 httpd daemons will run; the first will be a root process, and
the others will be "webservd" processes. We do not want any
httpd daemon to be owned by root. Since apache2 will be under the control
of the Solaris 10 Service Management Facility, we will use
"svccfg" to modify some properties.
solx# zlogin web
# svccfg -s apache2
svc:/network/http:apache2 setprop start/user = astring: webservd
svc:/network/http:apache2 setprop start/group = astring: webservd
svc:/network/http:apache2 end
There are a lot more properties you can set. Have a look at them!
# svccfg -s apache2
svc:/network/http:apache2 listprop
(output skipped).
svc:/network/http:apache2 exit
If we wanted to use an RBAC profile to set properties
for apache2, we would need to specify which profile we wanted to use by
setting the "profile" property. But in this example, we are not
going to use a profile so we set the "use_profile" property to
"false". This means that we have to set some other properties
manually for apache2 to start successfully. The most important one is the
"privileges" property. We take away some privileges to limit
process control, and add a privilege that will allow the httpd process to
bind to a private port, since the webservd will be the owner of the first
httpd process and is by default not allowed to bind to port 80, which is a
private port:
# svccfg -s apache2
svc:/network/http:apache2 setprop start/use_profile = boolean: false
svc:/network/http:apache2 setprop start/privileges = astring: \
basic,!proc_info,!proc_session,!file_link_any,net_privaddr
svc:/network/http:apache2 setprop start/limit_privileges = astring: :default
svc:/network/http:apache2 setprop start/supp_groups = astring: :default
svc:/network/http:apache2 setprop start/working_directory = astring: :default
svc:/network/http:apache2 setprop start/project = astring: :default
svc:/network/http:apache2 setprop start/resource_pool = astring: :default
svc:/network/http:apache2 end
Refresh Apache:
# svcadm -v refresh apache2
Action refresh set for svc:/network/http:apache2.
Reduce the Number of Services
Our zone is to be connected to the Internet and will
function as a Web server. So there is little need for all kinds of services
that don't matter; we do not want to invite the general hacker. You
can manually configure your zone not to run these services. You can also
simply copy an xml file that excludes all non-needed services:
# cd /var/svc/profile
# mv generic.xml generic.orig.xml
# ln -s generic_limited_net.xml generic.xml
# svccfg apply /var/svc/profile/generic.xml
Finally, get your daemons running:
solx# svcadm enable apache2
Check whether "webservd" is the owner of all httpd processes:
# ps -ef | grep httpd | grep -v grep
webservd 12972 12968 0 01:34:55 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 12969 12968 0 01:34:55 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 12970 12968 0 01:34:55 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 12971 12968 0 01:34:55 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 12976 12968 0 01:35:22 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 12968 11128 0 01:34:54 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 12973 12968 0 01:34:55 ? 0:00 /usr/apache2/bin/httpd -k start
Check the privileges and see that the Effective, Inherited, and Permitted sets now have very limited privileges:
# ppriv -v 12968
12968: /usr/apache2/bin/httpd -k start
flags = none
E: net_privaddr,proc_exec,proc_fork
I: net_privaddr,proc_exec,proc_fork
P: net_privaddr,proc_exec,proc_fork
L: contract_event,contract_observer,file_chown,file_chown_self,
file_dac_execute,file_dac_read,file_dac_search,file_dac_write,
file_link_any,file_owner,file_setid,ipc_dac_read,ipc_dac_write,
ipc_owner,net_icmpaccess,net_privaddr,proc_audit,proc_chroot,
proc_exec,proc_fork,proc_info,proc_owner,proc_session,proc_setid,
proc_taskid,sys_acct,sys_admin,sys_audit,sys_mount,sys_nfs,sys_resource
Troubleshoot
If things don't work the way you want them to,
the following logs may help:
/var/adm/messages
/var/svc/log/network-http:apache2.log
/var/apache2/logs/error_log
Keep in mind that if you want to set up your HTML
documents and cgi-bin, you will have to do that from within the global
zone's /apacheapache2/files directory, since Apache mounts this
directory read-only.
Conclusion
Zones and privileges do not replace RBAC or make RBAC
superfluous. They do seem to add a major improvement to Solaris system
security, however. The techniques can very well live side by side and
complement one another.
Peter van der Weerd works as a freelance Solaris, HP-UX, and Linux trainer in Europe.
|