[redhat-lspp] Xinetd patch

[schaufler-ca.com - Casey Schaufler]

How we did it in the Unix world, which you can
choose to take as either advice or warning.

The inetd process runs with sufficient privilege
(as root or with "sufficient" capabilities, depending
on the era and implementation) and with the
required socket options set (varies again with
era and implementation) to allow reading of
packets at any MLS value. The inetd process
requests the MLS value associate with the
connection. A child process is then created with
that MLS value, and the appropriate program
invoked. Of course, if there's already such a
process available (that service at that MLS value)
the usual processing may be done, although some
implementations choose not to do so to make it
easier to describe object reuse policy.

For this scheme to be viable you need several
things. First, you have to have a reliable interface
for getting the MLS value for all connections.
This can be done at the granularity of connection,
host, interface, or any combination thereof. The
TSIX interfaces ended up being popular. Second,
you have to be very careful about the services
you provide, especially those that do not require
user authentication. Those that do still have to check
that the user "logging in" is cleared for that MLS
value, and prevent the user from specifing a
different MLS value than that of the connection.
Finally, you need a way to identify those services
that can be trusted to enforce MLS policy so
that you can pass the responsibilities along.

We wanted to make change just to inetd, but
in the end found that we had to enhance both
inetd and most of the services invoked.



------------------------
Casey Schaufler
casey at schaufler-ca.com
650.906.1780