Running programs in controlled environment
When flexibility, speed and security can go hand in hand
On Shared libraries I said that running the programs into a controlled
environment can avoid the Shared libraries attack. Well, there is much more than that.
This is a perfect example of how flexibility, convenience and security can goes hand in hand. Not just it help avoiding the shared library attack,
but it also provide a easy way of installing individual programs in his own location. For example, KDE programs search for
their resources relatively to the paths listed into the KDEDIRS environment variable. If one wish to install a big number
of KDE programs each into his own directory, he have to update KDEDIRS with a big number of directories.
This not just will slow down the programs (who have to search a very large number of directories till find what it need) but in case
we want to have 2 or more different versions of the same program, we can get conflicts betwen resources.
The same is valid for
shared libraries directories (imagine a LD_LIBRARY_PATH with 100 or more entries) and with PATH (since many packages come with
auxiliary executables, it rely on PATH for finding them). It is obviously, that a version of LD_LIBRARY_PATH attack, can work for PATH
variable too. So, by having the possibility to start programs into a controlled environment, we can get benefits in: security, flexibility and speed.
How to achieve that
Sys++ components for running programs in controlled environment
The easy way to run a program into a controlled environment is to use a shell script who set the environment variables it need,
then exec the program. Well, as I presented in ShLib controlled, a eventually virus, may use
LD_PRELOAD variable to attack the exec* family of function from /bin/bash. This is possible since bash is
dynamically linked with libc. By doing so, it(the virus) get the opportunity to reverse all the security settings done by script,
thus letting the target program vulnerable to LD_PREALOD and/or LD_LIBRARY_PATH attack. Another problem with using a bash
script is that it proliferate the"overscripting abuse". A bash script is not easy to manipulate by GUI editors,
and it need to be edited/maintained by a administrator rather than a automated program. This is not the way to go, especially
for "Unix on desktop".
The solution I propose, is a small program self contained(statically linked) so it doesn't depend
by any shared library (thus invulnerable to shared library attack). This program will read a XML file (rather than a bash program),
who describe the environment the program have to run into. This XML file is much easy to edit than a bash script, and can be
managed by software rather than by humans (with vi, joe or emacs:-). The XML file, also enable that every program (started
by such a file) have associated with it a icon, a description, electronic signature and so on. Better than in Windows, isn't it :-)
Sys++ environment controllers
In Sys++, there come 3 different programs, intended to run another program into a controlled environment:
- /bin/uexec
Acronym from user exec. It will start a program with the same rights of the current user.
The only things specified in XML file are: the environment variables, the current working directory, the files where stdin,stdout,stderr are redirected by default
and some GUI related "candies". If a feature is not specified, it is inherited from the current user settings and environment. There are 3 exceptions: LD_PRELOAD
and LD_LIBRARY_PATH and PATH. LD_PRELOAD, if not specified in XML file is cleared out. LD_LIBRARY_PATH if not specified in file is initialized to the
system trusted lib directories. PATH if not specified, is defaulted to the system trusted binary directories.
- /bin/suexec
Acronym from super exec. This program is setuid root. Beside the uexec settings, it
handle the following settings: uid, euid,gid,egid ,supplementary groups of the program to start and posix capabilities the program may have.
This file may also specify which PAM entry this program obey.
- /bin/nexec
Acronym from network exec. It is the answer to the users desire to be able to send executable toys over e-mail.
Hopefully, as of today, no e-mail program allow you to doubleclick on a attachment and start the exe file, or download and execute directly a program.
This is both secure, but inconvenient for the users (who "need badly" this "feature"). Well, to "make happy both the goat and the cabbage" we need a network executable format.
This is as mater of fact a tar archive, containing the executable, nonstandard libraries, resource files. Supplementary, it
have a XML file index.xml and a number of index_XXX.gpg who are a detached PGP signature of the index.xml. Index.xml is somehow similar with the
suexec format, except that it have a section having a MD5 checksum for every file into archive. The nexec may be declared a MIME type,
so any click in mail program or browser will start nexec for a file of that type. nexec first check the validity of the
PGP signature, and the value of MD5 checksums. If everything match, then it is sure, that we got what it was send by the one who
signed the program. Then, it look into the system trust database to identify the level of trust that can be granted
to that program(based on level of trust of a particular public key): There are 3 levels allowed by nexec for a network program: app-trust, user-trust and unknown-trust.
The systen-trust is granted only for vendor package, and is therefore not available for a network program. If the NE, have app-trust, it can be started if required with the rights of another
user (except, root, sys and a couple of other system reserved users). The user-trust level allow a NE to start the program within his current rights (however many trusted programs may
refuse to be started by a user-trusted NE). If the trust for that key is unknown-trust (ot the key is not present in system or user trust databases), this program
is allowed to run only after the user acknowledge a warning message, and is allowed to run only within a chroot jail and
with the rights of a untrusted uid. Here, it may be required a kernel module, who will forbid for a program running under untrusted account to bind or
connect an AF_INET socket. A library (LD_PRELOAD) may override these functions from libc so any
of these request are redirected to nexec who work into a supervision loop. That way, any malicious acts of a program received from
a unknown person may be avoided, however the program may be started to display a "Merry Christmas" card on the desktop. However, if a particular key
is revoked or it is declared as malicious into the system database (who is on line updated from a advisory server) the nexce
will refuse to run this program even into a chroot jail.
The executables for these 3 programs and the GUI for managing the trust database, will be available for download
from this page some times in near future. Keep watch it.
Advanced Unix programming techniques page
Sys++ Project Home page
Visit M.T.M. Home Page