Date: Sat, 29 Jun 2002 02:41:57 -0700 (PDT) From: Chris Costello <chris@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 13585 for review Message-ID: <200206290941.g5T9fv6b046536@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://people.freebsd.org/~peter/p4db/chv.cgi?CH=13585 Change 13585 by chris@chris_holly on 2002/06/29 02:41:04 Add in the LOMAC article as-is. Note that the pre-formatted bits like <programlisting> have been filled--this was a side-effect of the Emacs sgml-fill-element function. They will be re-formatted once it's determined what stays and what goes. Affected files ... .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#4 edit Differences ... ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#4 (text+ko) ==== @@ -973,10 +973,669 @@ policy.</para> </sect3> + <!-- TO BE LARGELY REWRITTEN. --> <sect3 id="mac-lomac"> + <sect3info> + <authorgroup> + <author> + <firstname>Tim</firstname> + <surname>Fraser</surname> + <affiliation> + <orgname>NAI Labs</orgname> + </affiliation> + </author> + + <author> + <firstname>Chris</firstname> + <surname>Costello</surname> + <affiliation> + <orgname>Safeport Network Services, NAI Labs</orgname> + </affiliation> + </author> + </authorgroup> + </sect3info> + <title>Biba Low-Watermark Integrity Protection</title> - - <para>This section will document the LOMAC policy.</para> + + <para>LOMAC is a loadable kernel module-based security + extension available on a number of UNIX kernels. LOMAC + provides Low Water-Mark Mandatory Access Control + functionality to protect the integrity of processes and data + from viruses, Trojan horses, malicious remote users, and + compromised <username>root</username> daemons. LOMAC is + designed to be virtually invisible to users, and largely + painless to administrators.</para> + + <para>This is the operations manual for LOMAC. It describes + LOMAC and the protection LOMAC provides. Please note that + the FreeBSD version of LOMAC is still under development. + Although enough functionality exists to provide some useful + protection, some features and fixes remain to be + implemented. The FreeBSD version of LOMAC should be used for + experimental purposes only at this time.</para> + + <sect4> + <title>Introduction</title> + + <indexterm> + <primary>MAC</primary> + </indexterm> + + <para>Several projects have demonstrated that + kernel-resident Mandatory Access Control + (<acronym>MAC</acronym>) mechanisms can protect the + integrity of Free UNIX systems from malicious code and + users. However, implementations of these mechanisms have + traditionally required invasive kernel modifications, + sometimes coupled with supporting modifications of + user-space utilities, as well. This requirement has + hindered the adoption of MAC mechanisms in the mainstream + Free UNIX community. Adoption has been further discouraged + by the difficulty of starting small and evolving towards a + complete MAC solution - in general, the complete set of + extensive modifications must be made before MAC can + provide any useful protection.</para> + + <para>LOMAC is an attempt to make an easily-adoptable form + of MAC integrity protection available to the Free UNIX + community without the discouraging necessity of kernel + modifications. LOMAC implements a simple form of MAC + integrity protection based on Biba's Low Water-Mark model + in a Loadable Kernel Module (LKM) Although it trades off + some of the advanced MAC features found in traditional MAC + implementations, LOMAC provides useful integrity + protection without any modifications to the kernel, + applications, or their existing configurations. LOMAC is + designed to be compatible with existing software, and + ships with a one-size-fits-all default configuration. + LOMAC may be used to harden cur rently-deployed FreeBSD + systems simply by loading the LKM into the kernel shortly + after boot time.</para> + + <para>Once loaded, LOMAC divides the system into two + conceptual levels of integrity: high and low. The high + side contains all process and files that should be + protected from malicious code and remote users, including + the system binaries (<filename>/bin</filename>, + <filename>/lib</filename>) and configuration files + (<filename>/etc</filename>). The low side contains the + processes that interact with remote users (remote login + sessions, <application>httpd</application>) and the files + they download from the net (mail attachments). Low files + may contain viruses or Trojan Horses. Low processes take + input from remote users that may cause buffer overflows. + During run-time, LOMAC protects high files and processes + by preventing low processes from modifying or signalling + them. Thanks to is generic default configuration, LOMAC + handles the division of the system into high and low parts + automatically, without administrative direction.</para> + + <para>LOMAC does not override the existing FreeBSD + protection mechanisms. Instead, its permission checks are + done in addition to the existing ones—the kernel + permits an operation only if both the existing mechanisms + and LOMAC decide it should permit it. Unlike the existing + FreeBSD protection mechanisms, LOMAC makes decisions based + solely on integrity level, not on user identity. With + LOMAC, a low-level <username>root</username> process is + just as powerless as a low-level + non-<username>root</username> process. Since LOMAC + automatically places all network servers in the low part + of the system, this fact prevents compromised + <username>root</username>-privileged network servers from + harming the high-integrity part of the system.</para> + </sect4> + + <sect4 id="short-tour"> + <title>A Short Tour</title> + + <para>This section introduces LOMAC's major features. You + may follow these steps the first time you boot with LOMAC + running to ensure that your installation is + correct.</para> + + <orderedlist> + <listitem> + <para>Log in as <username>root</username>, from the + system console.</para> + </listitem> + + <listitem> + <para>Check to make sure that the LOMAC LKM is + loaded:</para> + + <screen># /sbin/kldstat | grep lomac.ko 5 1 + 0xc13e0000 c000 lomac.ko</screen> + </listitem> + + <listitem> + <para>Look at the levels of your processes:</para> + + <screen># ps PID LVL TT STAT TIME COMMAND 251 2 + v6 Is 0:00.37 login -p root 650 2 v6 S + 0:00.56 -csh (csh) 665 2 v6 R+ 0:00.05 + ./ps</screen> + + <para>Note that all your processes are running at level + 2—LOMAC's highest level of privilege.</para> + </listitem> + + <listitem> + <para>Look at the levels of your files. + (<literal>-Z</literal> shows levels.)</para> + + <screen># ls -lZ total 62 -rw-r--r-- 2 root wheel 2 + 802 Apr 21 2001 .cshrc -rw------- 1 root wheel 2 + 2973 Oct 12 09:41 .history -rw-r--r-- 1 root wheel + 2 142 Apr 21 2001 .klogin -rw-r--r-- 1 root wheel + 2 297 Apr 21 2001 .login ...</screen> + + <para>Note that all your files are also at level 2. + Level-2 files are high-integrity—LOMAC assumes + that they contain no viruses or Trojan horses at boot + time, and limits the behavior of processes during + run-time to keep them that way.</para> + </listitem> + + <listitem> + <para>Look at the levels of a normal user's files. I'll + use the user tfraser in the example; you'll have to + use one of your own users.</para> + + <screen># ls -laZ /home/tfraser total 47 drwxr-xr-x 8 + tfraser staff 1 1024 Oct 25 14:30 . drwxr-xr-x 4 + root wheel 2 512 Aug 27 10:47 .. -rw------- 1 + tfraser staff 1 114 Aug 27 11:11 .Xauthority + -rw------- 1 tfraser staff 1 42 Oct 4 10:17 + .bash_history</screen> + + <para>Note that while <filename>/home</filename> is + level 2 (high integrity), all of the user's files are + level 1 (low integrity). LOMAC assumes that any of the + user's files may be Trojan horses or contain + viruses.</para> + </listitem> + + <listitem> + <para>Examine one of the user's files with less, and put + less in the background with ctrl-Z. Then run ps to + look at your processes.</para> + + <screen># less /home/tfraser/.bash_history <output + not included in document to save space> ^Z + Suspended # ps PID LVL TT STAT TIME COMMAND 251 + 2 v6 Is 0:00.37 login -p root 650 2 v6 S + 0:01.28 -csh (csh) 733 1 v6 T 0:00.08 less + /home/tfraser/.bash_history 735 2 v6 R+ + 0:00.05 ./ps</screen> + + <para>Note that, although your shell + (<application>csh</application> in my case) is still + at level 2, the process running less is at level 1. + Here's why: Processes generally inherit the level of + their parent. So, any process you start with your + level-2 shell will initially execute at level 2. The + less process was no exception - it began running at + level 2. However, the less process went on to read the + user's <filename>.cshrc</filename> file. This file is + a level-1 file—it contains low-integrity data. + Whenever LOMAC sees a level-2 process read a level-1 + file, LOMAC "demotes" the process. That is, it reduces + the process to level 1.</para> + + <para>Level-2 processes have maximum privileges (like + <username>root</username> in standard UNIX). Level-1 + processes have greatly reduced privileges. For + example, they cannot write to level-2 files, or signal + level-2 processes. When a level-2 process reads a + level-1 file, it puts itself at risk. The file may be + a Trojan horse or may contain data designed to cause + buffer overflows. Because of this risk, LOMAC demotes + level-2 processes that read level-1 files to level 1. + Once at level 1, these processes have insufficient + privilege to harm level-2 processes and files.</para> + + <para>Many cautious UNIX administrators avoid putting + "." in their PATH environment variable, in order to + avoid executing some Trojan horses. In standard UNIX, + a malicious user might give an attack program the same + name as a commonly-used command like ls. If the + administrator, running as <username>root</username>, + were to cd to the malicious user's directory and type + ls, if the "." preceded <filename>/bin</filename> in + their path, they would accidentally execute the + malicious <application>ls</application> rather than + <filename>/bin/ls</filename>. This act would + effectively execute the malicious user's Trojan horse + program with <username>root</username> privileges, + perhaps to modify the login program or the + <filename>passwd</filename> file.</para> + + <para>This precaution is not required in a system + running LOMAC. LOMAC considers the execution of a + program to be equivalent to a read (since the process + reads the program file in order to execute it). Since + all non-<username>root</username> user's files are at + level 1, LOMAC would demote the process executing the + Trojan ls, just as it demoted less in our example, + above. Once at level 1, LOMAC would prevent the Trojan + ls from modifying level-2 files such as the login + program or the passwd file.</para> + + <para>Demotion is a key part of the LOMAC's integrity + protection scheme. Now that we've demonstrated how it + works, we're now done with less. Quit the less + program.</para> + + <screen># fg <output not included in document to save + space> q</screen> + </listitem> + + <listitem> + <para>Create a test file. We'll use this test file to + demonstrate LOMAC's integrity protection later + on.</para> + + <screen># cat > /root/foo This file contains test data. + ^D</screen> + </listitem> + + <listitem> + <para><command>tail -f + /var/log/messages</command></para> + + <para>Leave this running while you continue the tour. + It's output will contain LOMAC log messages as we + proceed.</para> + </listitem> + + <listitem> + <para>Switch to another virtual console and log in as a + normal user. Once logged in, examine the levels of + your processes:</para> + + <screen>$ ps PID LVL TT STAT TIME COMMAND 742 1 + v7 S 0:00.48 -tcsh (tcsh) 750 1 v7 R+ + 0:00.05 ps</screen> + + <para>Note that as a normal user, all of your processes + are at level 1. Why? Switch back to the virtual + console where you are logged in as + <username>root</username>. You should see a log + message similar to:</para> + + <programlisting>Oct 25 14:44:54 myhost + /boot/kernel/kernel: LOMAC: level-2 subject + p252g252u1002:login demoted to level 1 after reading + under "/usr/home"</programlisting> + + <para>All the getty programs that handle logins run at + level 2. When a user attempts to log in, they run the + login program, which also runs at level 2. Upon + supplying the proper password, the login program + starts a shell for the user + (<application>tcsh</application> in this case). The + shell starts at level 2, but LOMAC demotes it to level + 1 when it reads the user's <filename>.cshrc</filename> + file, just as it demoted the less program, above. Once + the user's shell is running at level 1, all of the + programs subsequently executed by the user will run at + level 1, also.</para> + + <para>Our <username>root</username> shell from the start + of the tour remains at level-2 because LOMAC has set + all of <username>root</username>'s files at level 2. A + level-2 process may read level-2 files without being + demoted. The user's shell is demoted because it reads + the user's level-1 files. LOMAC does not assign levels + to processes based on the user's + <username>root</username>/non-<username>root</username> + identity. LOMAC assigns levels to files by starting + the first process (init) at level 2, allowing child + processes to inherit their parent's level, and by + demoting processes that read level-1 files. LOMAC does + not pay any attention to user identity. Consequently, + LOMAC is not vulnerable to any of the traditional + attacks on UNIX security that involve obtaining + <username>root</username> identity.</para> + </listitem> + + <listitem> + <para>Test the above assertion that LOMAC does not give + any extra privileges to processes with + <username>root</username> identity. Switch back to the + normal user's shell and become + <username>root</username>.</para> + + <screen>&prompt.user; su Password: # ps PID LVL TT STAT + TIME COMMAND 252 1 v7 Is 0:00.39 login -p + tfraser 751 1 v7 I 0:00.18 su 752 1 v7 S + 0:00.43 _su (csh) 755 1 v7 R+ 0:00.05 ps</screen> + + <para>Note that, despite the <command>su</command>, your + shell is still at level 1. LOMAC never increases the + level of a process. Now attempt to delete the + <filename>/root/foo</filename> file you created + earlier.</para> + + <screen># ls -lZ /root/foo -rw-r--r-- 1 root wheel 2 + 30 Oct 25 14:44 /root/foo # rm /root/foo rm: + /root/foo: Operation not permitted</screen> + + <para>Even though you are <username>root</username>, + LOMAC will not allow a level-1 process + (<command>rm</command> in this case) to delete a + level-2 file. You should see a log message similar to + this one in on the <username>root</username> virtual + console that is tailing /var/log/messages:</para> + + <programlisting>Oct 25 14:50:52 myhost + /boot/kernel/kernel: LOMAC: level-1 proc p763g763u0:rm + denied delete to level-2 object under + "/"</programlisting> + + <para>This concludes the short tour.</para> + </listitem> + </orderedlist> + </sect4> + + <sect4> + <title>LOMAC and Network Applications</title> + + <para>This section explains how LOMAC uses its demotion + behavior to ensure that all remote users and servers that + serve remote users (<application>httpd</application>, + <application>ftpd</application>, etc.) run at level 1. At + this level, malicious remote users and compromised network + servers can do little harm to the level-2 part of the + system, even if they have <username>root</username> + privilege. It also discusses a few of the finer points + concerning LOMAC's protection scheme not already covered + in the <link linkend="short-tour">Short Tour</link> + section, above. The basic elements of LOMAC's integrity + protection scheme are summarized here:</para> + + <orderedlist> + <listitem> + <para>LOMAC assigns every process, or named filesystem + object (file, named pipe, or bound UNIX-domain socket) + a level: either 1 (low integrity) or 2 (high + integrity).</para> + </listitem> + + <listitem> + <para>LOMAC assigns levels to filesystem objects based + on their location in the filesystem namespace. The + mapping between names and levels constitutes most of + LOMAC's "default policy", and is presently hardcoded + into the LKM. Once assigned, the levels of filesystem + objects never change.</para> + </listitem> + + <listitem> + <para>The first process (init) starts at level 2. All + child processes inherit the level of their parent. + Only when a level-2 process reads from a level-1 + object does LOMAC demote the process to level + 1.</para> + </listitem> + + <listitem> + <para>Level-1 processes have insufficient privilege to + write to level-2 objects or signal level-2 processes. + This protects the level-2 part of the system from + malicious interference.</para> + </listitem> + + <listitem> + <para>The combination of LOMAC's demotion behavior and + its restrictions on the privileges of level-1 + processes prevent malicious level-1 users from harming + the level-2 part of the system, even in cases where + level-2 administrators accidentally execute malicious + user's Trojan horses.</para> + </listitem> + </orderedlist> + + <para>In UNIX, network servers are generally started + automatically by the init process, or by one of its + children. With LOMAC, this arrangement guarantees that + network servers inherit the init process's level of 2. In + addition to demoting level-2 processes upon reading + level-1 files, LOMAC also demotes level-2 processes when + they read from a network interface. Consequently, LOMAC + demotes network server as soon as they read their first + client request from the network. Just as LOMAC assigns + appropriate levels to user shells based on their + file-reading behavior, not their user's identity, this + scheme allows LOMAC to demote network servers without + initially knowing which programs are network servers: + LOMAC simply allows the init program to start all of its + servers at level 2, and subsequently demotes those servers + which read from a network interface.</para> + + <para>LOMAC uses the same strategy to ensure that remote + users run at level 1: it demotes the remote login + (telnetd, rlogind) servers when they receive their first + login request, as described above. LOMAC's ability to + automatically determine the proper levels for users and + servers during runtime is the feature which allows it to + avoid site-specific configuration and ship with a + one-size-fits-all default policy.</para> + + <para>Here is an example of an httpd server before it reads + its first request. Note that the httpd server is comprised + of 5 processes, all at level 2.</para> + + <screen># ps -U nobody PID LVL TT STAT TIME COMMAND + 369 2 ?? I 0:00.03 /usr/local/sbin/httpd 370 2 + ?? I 0:00.03 /usr/local/sbin/httpd 371 2 ?? I + 0:00.03 /usr/local/sbin/httpd 372 2 ?? I 0:00.03 + /usr/local/sbin/httpd 373 2 ?? I 0:00.03 + /usr/local/sbin/httpd</screen> + + <para>After httpd reads its first request from the network, + you should see a message similar to this one in + /var/log/messages:</para> + + <programlisting>Oct 25 16:16:24 myhost /boot/kernel/kernel: + LOMAC: level-2 subject p369g368u65534:httpd demoted to + level 1 after reading from the network</programlisting> + + <para>And running ps again will produce:</para> + + <programlisting> PID LVL TT STAT TIME COMMAND + 369 1 ?? S 0:00.30 /usr/local/sbin/httpd 370 2 + ?? I 0:00.03 /usr/local/sbin/httpd 371 2 ?? I + 0:00.03 /usr/local/sbin/httpd 372 2 ?? I 0:00.03 + /usr/local/sbin/httpd 373 2 ?? I 0:00.03 + /usr/local/sbin/httpd 1572 2 ?? S 0:00.06 + /usr/local/sbin/httpd</programlisting> + + <para>LOMAC demoted httpd process 369 as soon as it read its + first client request.</para> + </sect4> + + <sect4> + <title>LOMAC and Traditional UNIX Access Control</title> + + <para>LOMAC does not override the existing FreeBSD + protection mechanisms. Instead, its permission checks are + done in addition to the existing ones—the kernel + permits an operation only if both the existing mechanisms + and LOMAC decide the kernel should permit it.</para> + + <para>There are three main differences between the integrity + protection scheme implemented by LOMAC and traditional + UNIX security mechanisms:</para> + + <orderedlist> + <listitem> + <para>Traditional UNIX provides mechanisms by which + processes can increase their privileges by changing + their effective identities. Although UNIX systems can + be configured to prevent malicious users from + exploiting these mechanisms in most cases, they can + also be misconfigured, and good configurations can be + foiled by bugs in user-space application programs. + LOMAC provides no mechanism to allow a process to + increase its level.</para> + </listitem> + + <listitem> + <para>Traditional UNIX access control mechanisms are not + designed to prevent the flow of potentially dangerous + data from low-integrity objects to high-integrity + objects. That is, from files owned by one user to + those owned by another - even to those owned by + <username>root</username>. The Trojan ls scenario in + the <link linkend="short-tour">Short Tour</link> + section describes one well-known example of this + vulnerability, and how LOMAC counters it.</para> + </listitem> + + <listitem> + <para>Although many enhancements now exist, in its most + basic form traditional UNIX depends on easily defeated + authentication mechanisms to establish appropriate + initial privilege levels. LOMAC assigns privilege + levels to processes based on their reading behavior. + As described above, the effect of LOMAC's policy is to + give the highest level of privilege only local + administrative users, and the lowest level of + privilege to all others, regardless of identity. LOMAC + does not consider user identity; consequently, it does + not depend on authentication.</para> + </listitem> + </orderedlist> + </sect4> + + <sect4> + <title>Limits of LOMAC's Protection</title> + + <para>LOMAC embodies a trade-off between quality of MAC + protection and compatibility. LOMAC's primary goal is to + remain compatible with existing software while providing + some useful MAC integrity protection. The Low Water-Mark + MAC model supports this compatibility-first requirement. + However, it the quality of protection it provides is not + as great as that provided by more modern, less compatible, + models. This issue is discussed at length in. This section + presents the two well-known primary quality-of-protection + drawbacks of the Low Water-Mark model: its enforcement of + the principle of least privilege, and its reliance on + trusted applications.</para> + + <para>The first drawback of the Low Water-Mark MAC scheme + concerns the Principle of Least Privilege, which holds + that a good MAC scheme should grant a subject the minimum + set of privileges needed to do its job [SAL75]. + Constraining a subject in this way minimizes the amount of + damage the subject can cause should it become compromised. + Low Water-Mark provides weaker constraints than some more + modern models. The LOMAC AND NETWORK APPLICATIONS section + describes how LOMAC protects the level-2 part of the + system by demoting network servers to level 1. Although + LOMAC will prevent a compromised level-1 network server + from harming the level-2 part of the system, LOMAC will + not prevent such a server from doing harm in the level-1 + remainder of the system. A compromised + <username>root</username>-privileged network server could, + for example, send kill signals to another level-1 + server.</para> + + <!-- BIBLIO REFERENCE --> + <para>The second drawback of the Low Water-Mark MAC scheme + is its reliance on trusted applications. This reliance is + a feature of hierarchical models like Low Water-Mark + [BOE85]. The dhclient(8) client-side DHCP agent is a good + example of LOMAC's reliance on trusted applications: As + described in the LOMAC AND NETWORK APPLICATIONS section, + LOMAC protects the integrity of the level-2 part of the + system by demoting all applications which read from the + network to level 1. Once demoted, these applications can + no longer modify level-2 files. Although this demotion and + confinement prevents potentially-compromised network + applications provides useful protection, it also prevents + applications like dhclient from operating properly.</para> + + <para>The dhclient application reads DHCP information from + the network and attempts to update the host's + <filename>/etc</filename> configuration files, + accordingly. This is exactly the kind of + potentially-dangerous behavior that is prohibited by + LOMAC; a dhclient that LOMAC has demoted to level 1 cannot + modify <filename>/etc</filename> configuration files. + Although dangerous, dhclient's behavior is required for + the proper operation of some systems.</para> + + <para>LOMAC must provide an exception to its policy in order + to allow dhclient to run, and "trust" dhclient not to + abuse this exceptional privilege. LOMAC sets the special + "NONETDEMOTE" flag on all processes running the dhclient + program. LOMAC will not demote a process with this flag + set when that process reads from the network. This + exception allows a level-2 dhclient to stay at level 2 + after reading DHCP information from the network, + permitting it to modify <filename>/etc</filename> + configuration files as it chooses.</para> + + <para>The FreeBSD version of LOMAC presently two flags for + processes, each implementing a specific flavor of + trust:</para> + + <variablelist> + <varlistentry> + <term> + <constant>NONETDEMOTE</constant> + </term> + + <listitem> + <para>LOMAC will not demote a processes after reading + from the network provided that it has this flag + set.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <constant>NODEMOTE</constant> + </term> + + <listitem> + <para>LOMAC will never demote a process that has this + flag set.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>Note that, although these flags allow level-2 + processes to escape demotion, they do not allow a level-1 + process to raise its level to 2. LOMAC does not provide + any such promotion mechanism.</para> + + <para>LOMAC will set a process's + <constant>NONETDEMOTE</constant> or + <constant>NODEMOTE</constant> flag when that process + executes a particular program, such as dhclient. In + addition, once a process has one of these flags set, any + children it subsequently creates will have the same flag + set. LOMAC maintains a short list mapping programs to + process trust flags. Eventually, that list will be shown + here. However, since the FreeBSD version of LOMAC is still + under development, the membership of the list is still + fluid. The best reference is the LOMAC source code, + specifically <filename>policy_plm.h</filename>.</para> + + <para>If you create symlinks to <filename>env</filename> + named <filename>env-nonetdemote</filename> and + <filename>env-nodemote</filename> , executing env through + these symlinks will cause env and its child processes to + run with the <constant>NONETDEMOTE</constant> and + <constant>NODEMOTE</constant> flags, respectively. This + feature may be an aid to administration, particularly when + downloading and installing new software.</para> + </sect4> </sect3> <sect3 id="mac-mls"> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206290941.g5T9fv6b046536>