jm> How would low watermark help a typical web/file/database/application
jm> server? What about a firewall, or a desktop system?
Low Water-Mark is analogous to Perl's taint-mode applied to processes
instead of Perl expressions. In taint-mode, Perl marks expressions
that read input from potentially malicious sources as "tainted" and
uses run-time checks to prevent "tainted" parts of a Perl program from
performing certain security-relevant operations. Similarly, typical
Low Water-Mark schemes mark processes that read input from potentially
malicious sources as "tainted" and use run-time (LSM) checks to
prevent them from performing certain security-relevant operations.
That's the basic idea.
Here is how you might configure a Low Water-Mark LSM module to provide
some useful integrity protection in a simple one-size-fits-all package
applicable to each of the examples cited by James Morris, above. Give
all of your "system" files (/boot, /bin, /etc, and so on) a "high"
integrity label. Give the rest (/home) a "low" integrity label. Give
your network interfaces (eth0) a "low" integrity label, too. We'll
use this "low" label the same way Perl uses "tainted".
Our goal will be to prevent an adversary from modifying "high" data
either directly (perhaps by exploiting a buffer overflow in a network
server and issuing malicious commands through it) or indirectly
(perhaps by tricking a legitimate administrator into executing a
Trojan horse).
To meet this goal, make your LSM module enforce these rules:
(1) Give the first process on the system the "high" integrity label.
(2) By default, give child processes the same label as their parent.
(3) When a "high" process reads "low" data, change that process's
label to "low".
On boot, every process started by the init scripts initially gets the
"high" integrity label. However, as soon as a process (perhaps a
network daemon, web server, firewall proxy) reads "low" data (perhaps
its first client request from the network) the LSM module demotes that
process to "low" integrity. Note that we don't have to configure our
LSM with knowledge of what programs exist on a customer's machine in
order for rule (3) to assign processes the proper label. This freedom
makes it easier to provide a "one-size-fits-all" solution.
To provide protection, enforce this rule:
(4) "low" integrity processes cannot modify "high" integrity data.
This rule prevents an adversary from using a compromised network
daemon to directly modify "high" system files. Furthermore, it also
prevents an adversary from leaving a Trojan horse in a "high" file in
the hope that a legitimate admin will run it. The adversary could
leave a Trojan in a "low" file, but since the LSM module will demote
any process that reads that file as executable text or data to "low",
the protection is the same.
Of course, there are programs like DHCP clients that must read from
the network and subsequently write "high" system files in /etc.
Others, like syslogd, must read data from "low" clients on the local
system and subsequently write output to "high" log files. For these
programs, you need this final rule:
(5) Never demote programs in the special "trusted" program list.
This is how LOMAC used to work on 2.0 and 2.2 kernels. It had a list
of 11 trusted programs, including a LOMAC-specific "lup" program to
promote "low" files to "high". Just as Perl scripts need a mechanism
to remove "taint" after scrubbing input, LOMAC needed a way for an
admin to promote downloaded files deemed to be clean, such as .debs or
.rpms.
A security flaw in a trusted program might permit an adversary to
bypass the Low Water-Mark security mechanism. Consequently, a system
with 0 trusted programs would be better than one with 11. Still, 11
is better than relying on the correctness of *every* program that
reads potentially-malicious input. Note that these programs include
not only network clients and servers, but any program an admin might
run on data provided by local non-admin users.
I mentioned LOMAC only as a historical example. Dr. Safford's newer
SLIM module is the issue here, and I understand from his paper that he
improves upon LOMAC by applying TPM technology to trusted programs.
Sorry for the long post,
- Tim Fraser
This archive was generated by hypermail 2.1.3 : Sat Nov 19 2005 - 04:31:47 PST