From: Markus Mayer (mymaillists@gmx.at)
Date: Fri Jun 03 2005 - 09:31:08 EDT
Hi all,
First off, this is a long email, so read it when you have time.
I have an interesting problem for which I have a working solution, all be it
a bit of a hack, and would like to know if anyone sees a better solution.
This setup needs to go into test next week, and productive the following
week.
I want to set up some zones for www and ftp where each zone has its own IP
address. I am using whole root zones because I want nothing from the root
zone to be visible in the non global zone, things like /usr etc. The zones
should have the following:
- All directories with system binaries should be mounted read only. This
includes directories like bin, etc, usr, lib, ...
- All directories which contain data which changes should be mounted
rw,noexec. This includes directories like home, export, tmp, var, dev,
data mounts (htdocs, mysql_data, ftp_data), ...
- The zones should have the absolute minimum installed for them to run.
- The ftp and www zones would have their normal access from the internet.
- The root zone, and maybe a test zone, will be accessible only from a
specific subnet, otherwise they should not be visible from the outside
(ipfilter dropping packets from outside).
I realise this type of setup makes administration, especially when it comes to
patches, more difficult, however the prime intention of such a setup is to
deny an attacker any possibility of movement should they make it onto one of
the zones. It also provides for restrictions for users who should have
access to the zones.
I was able to achieve this kind of setup, all be it as a hack (please, if you
have some ideas, write them down before reading the following):
1: configure the zone as a whole root zone with:
- No inherited package directories (ok, whole root zone... clear)
- For every directory that contains system binaries, add an fs that is
loopback mounted to the corresponding directory from the copied zone
files (usr -> /zones/www-files/usr, ...)
This was done by (example for /usr):
add fs
set dir=/usr
set special=/zones/www-files/usr
set type=lofs
- For /var, /home, httpdata, ftpdata, ... set options=rw,noexec
- dev is the only directory where I was not able to do the above.
2: install and boot the zone.
3: Within the zone, pkgrm all unwanted packages.
4: install necessary software (own compiled and chrooted apache, proftpd, ...
with log file dirs somewhere like /var and limited access privs)
5: add necessary users
6: stop the zone
7: change the configuration of the fs of the zone so that all directories that
contain system binaries (/usr, /lib, /system, /opt, /etc, /platform,
/sbin) are read only. This was done by (example for /usr):
select fs dir=/usr
set options=ro
8: add net interface
9: boot zone
This all has some advantages and some disadvantages:
Advantages:
- Users are very limited in what they can do
- Zone admins can't mess around much at all and can't stuff up configs (I have
to give two access and one is particularly incompetent with Solaris, *nix)
- If the zone is cracked in any way, the cracker has virtually no possibility
to change any system files (this is the biggest reason for all of this)
- maybe some others that I can't think of now
Disadvantages:
- difficult to change passwords - requires stop, reconfig, boot, change
passwd, stop, reconfig, boot.
- applying patches requires similar steps for changing passwords
- updating third party software, such as our apache, proftpd requires root
zone admin intervention - either the above process for passwords, or by the
root zone admin putting the software in its place in the
/zones/www-files/... (the directories from the root zone are always rw,exec)
- It does not stop a cracker changing data files or defacing web pages
- If the root zone is cracked, the protections are worthless.
- maybe some others that I can't think of now
Also, at some point in the next few months, the installation should be
extended so that it runs on a load balancing cluster of two machines (I still
have no experience here). What I hope to achieve there is that when updates
have to be done, I can take a zone on one machone off line and do the
updates/changes while the corresponding zone on the other machine takes care
of providing services.
My questions are can I do this better or easier, and have I missed something?
My paranoia and possibly resulting insanity should, for the most part, be
ignored. If there are any questions about what I've written, please ask!
regards to all (especially if you read this far!)
Markus
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:30:49 EDT