By Paul Murphy, author of The Unix Guide to Defenestration
Sometimes you want to build as static a system as possible - a Solaris implementation that contains the absolute minimum needed to run exactly one application, often a web server and its database backend.
One of the big problems in doing this arises because you need to be sure that rarely called libraries or utilities are available when needed and you don't want to find out you missed something in one of those 3:30AM phone calls from user management.
Assuming you don't have full application source code the primary tools for this are truss and ldd.
For example reviewing the output from:
truss -f -o /tmp/truss_out -topen,open64,stat, exec your_test_program
will show you all the stuff that the application can open - although you will
want to make use of sort and uniq in reviewing its output!
And:
ldd -s your_program
will identify dynamic library dependencies and pathing.
Of course a lot of applications contain multiple executable components each of which you have to trace to ensure that a package dependency doesn't ultimately resolve to a library or other file you don't have but this is one of this situations where you just start with one and keep going until you're finished.
The same thing's true of patches - your restricted system should have all its patches, but Sun's patches often contain package dependencies and fail to install completely on a system configured for only one application. Again, it's a trial by doing kind of thing - install the latest patches and review the logs to see if you care about specific failures.
One thing you should be aware of in doing this is that environment variables can present points of
vulnerability. In principle a bad guy could, for example, modify LD_LIBRARY_PATH_64 to point
at his own libs so using crle to embed your own pathing directly in the config is
one of those things that professionals do whether they actually make sense for the local environment
or not.