Security in ACS

by Jin Choi

Chrooted AOLserver

In order to limit the amount of damage someone exploiting a security hole in ACS can do, it is possible to run AOLserver in a chroot environment (see The tricky part to doing this is setting up a root directory that will let the Oracle driver find all the files it needs to work.

Setting up the chroot directory

In order to keep things simple, we'll use the server directory as the new root (let's call it /home/aolserver). We need to recreate a few system directories and populate them:
cd /home/aolserver
mkdir bin dev etc tmp usr var

# Create some device files necessary for Oracle.
# (The following is Solaris specific.)
cd dev
mknod kmem c 13 1
mknod mem c 13 0
mknod zero c 13 12
mknod null c 13 2
chmod a+w zero

# Copy necessary files to /etc.
cd ../etc
cp /etc/group /etc/hosts /etc/nsswitch.conf /etc/resolv.conf /etc/netconfig .
grep nsadmin /etc/passwd > passwd

# Create a symlink as /home/aolserver, so we don't have to edit all our
# .ini files.
cd ..
mkdir home
ln -s . home/aolserver

# Make tmp directory world writable.
chmod 1777 tmp 
mkdir var/tmp
chmod 1777 var/tmp

# Copy rm to bin.
cp /bin/rm bin

# Copy unzip to usr/bin.
mkdir usr/bin
cp /usr/bin/unzip usr/bin

# Copy shared libraries to usr.
# Note that it may be desirable to recompile
# with static linked binaries to avoid having
# these libraries in the chroot environment.
# See dynamic_linking_notes
# to get a more accurate list of files needed.
mkdir usr/lib
cp /usr/lib/*.a /usr/lib/*.so.* usr/lib

# If using the ecommerce module with ImageMagick to do image resizing,
# copy ImageMagick files.
mkdirhier usr/local/bin
mkdirhier usr/local/lib
cp /usr/local/bin/convert usr/local/bin
cp /usr/local/lib/ImageMagick* usr/local/lib
mkdirhier usr/openwin/lib
cp /usr/openwin/lib/ usr/openwin/lib
cp /usr/openwin/lib/ usr/openwin/lib
cp /usr/openwin/lib/ usr/openwin/lib
cp /usr/openwin/lib/ usr/openwin/lib

# Copy timezone files.
mkdirhier usr/share/lib
cp -r /usr/share/lib/zoneinfo usr/share/lib

# The page root must also be within the chroot environment.
mkdir web
mv /web/servername /home/aolserver/web

# (Optional) make a link to the chrooted pages from the old web directory
ln -s /home/aolserver/web/servername /web/servername

# Copy necessary Oracle files to new root.
mkdirhier /home/aolserver$ORACLE_HOME
cd /home/aolserver$ORACLE_HOME
(cd $ORACLE_HOME; tar cf - bin dbs lib network ocommon rdbms) | tar xvf -

Setting up Oracle

Unfortunately, when running Oracle in dedicated server mode, each client process starts up its own server process which requires direct access to the data files. This will obviously not work in a chroot environment unless all the Oracle data files are contained within the chroot directory. This is not desirable and generally not possible.

One workaround for this is to connect to Oracle through a TCP connection. This is by far the easiest to set up. The downside is that there is some performance loss going through TCP instead of using IPC. To do this, edit $ORACLE_HOME/network/admin/listener.ora to add a TCP listener and $ORACLE_HOME/network/admin/tnsnames.ora to add a network alias for that listener (see the Net8 Administrator's Guide, or just use netasst). Then have AOLserver use it by putting the network alias as the Datasource entry for the connection pool in your server's .ini file.

If you insist on using IPC, you must configure the database to run in multi-threaded server (MTS) mode. Configuring MTS mode can be somewhat tricky (see this 8.1.5 doc and this 8.1.6 doc). In brief, you must:

To put Oracle into MTS mode, you must now restart the Oracle server. The listener should be started before the server so that the server can register itself properly with the listener. To verify that Oracle is in MTS mode, connect to Oracle using "sqlplus username/password@ora8_ipc" (substitute the network alias you put in tnsnames.ora for ora8_ipc), and run this SQL statement: select username, program, server from v$session where audsid=userenv('sessionid');. It should return "SHARED" in the SERVER column. If it says "DEDICATED" instead, your server is not in MTS mode.

One last problem with running ACS in a chrooted environment is that Oracle uses Unix domain socket files for IPC that are created in /var/tmp/.oracle. We must replace /var/tmp/.oracle with a symlink to a directory underneath the chroot directory. This must only be done with Oracle shut down!

cd /home/aolserver
mkdir var/tmp/.oracle
chown oracle var/tmp/.oracle
chmod 777 var/tmp/.oracle
# Make sure Oracle is not running before you do this next step!
rm -r /var/tmp/.oracle
ln -s /home/aolserver/var/tmp/.oracle /var/tmp/.oracle

A caveat about specifying directories in .ini files: every path must be relative to the chroot directory (e.g., /home/nsadmin/foo/bar -> /foo/bar), except for AuxConfigdir, which must be an absolute path.

Running AOLserver

At this point, you can run AOLserver using /home/aolserver/bin/nsd-oracle -ikc /home/aolserver/servername.ini -r /home/aolserver from inittab. This, however, introduces a way to get out of the chroot sandbox. The problem arises because /home/aolserver/bin/nsd-oracle and bin/nsd8x, which it calls, are run by init, as root, outside of the chroot environment. If someone were to replace either of those files with a shell script that executes some other program (such as "rm -rf /"), it will be executed by root.

The way to get around this problem is to move nsd8x, nsd-oracle, and the server.ini file outside of the chroot environment, and run it using /somewhere/not/in/chroot/nsd-oracle -ikc /somewhere/not/in/chroot/servername.ini -r /home/aolserver from inittab, where nsd-oracle calls /somewhere/not/in/chroot/nsd8x instead of the one within the chroot environment.

Running ACS

Several modules in the ACS depend on the existence of other programs. These programs should be installed in the appropriate directory under your web root (i.e. /home/aolserver):

Disk Issues

Chrooting a server requires that everything related to the running of AOLserver reside under a single directory. This may cause problems with disk space, since what before was split up onto two directories (the server root and the page root) now must go under the same directory. One workaround is to mount a separate disk as /home/aolserver/web and symlink it to /web.

Static Linking Notes

In order to avoid having shared libraries in the chroot environment, and in particular to avoid having PERL available, you may wish to recompile some binaries with static linking. This may be as simple as adding the "-static" flag to the gcc compile command. For PERL, it's a bit more involved (note that this is only required if you want to run watchdog, since that's the only place the webserver presently uses a PERL script):

Dynamic Linking Notes

If you're willing to have shared libraries in your chroot environment, then you'll want to make sure you have all of the .so files you need. There are two ways to do this: One last change for either static or dynamically linked: Edit your parameters.ini file and replace "" with just "aolserver-errors".