From owner-p4-projects Sat Jun 29 2:42:45 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 8F32237B400; Sat, 29 Jun 2002 02:41:59 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 085A037B401 for ; Sat, 29 Jun 2002 02:41:59 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B43BB43E13 for ; Sat, 29 Jun 2002 02:41:57 -0700 (PDT) (envelope-from chris@freebsd.org) Received: from freefall.freebsd.org (perforce@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g5T9fvJU046539 for ; Sat, 29 Jun 2002 02:41:57 -0700 (PDT) (envelope-from chris@freebsd.org) Received: (from perforce@localhost) by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g5T9fv6b046536 for perforce@freebsd.org; Sat, 29 Jun 2002 02:41:57 -0700 (PDT) Date: Sat, 29 Jun 2002 02:41:57 -0700 (PDT) Message-Id: <200206290941.g5T9fv6b046536@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: perforce set sender to chris@freebsd.org using -f From: Chris Costello Subject: PERFORCE change 13585 for review To: Perforce Change Reviews Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 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. + + + + + Tim + Fraser + + NAI Labs + + + + + Chris + Costello + + Safeport Network Services, NAI Labs + + + + + Biba Low-Watermark Integrity Protection - - This section will document the LOMAC policy. + + 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 root daemons. LOMAC is + designed to be virtually invisible to users, and largely + painless to administrators. + + 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. + + + Introduction + + + MAC + + + Several projects have demonstrated that + kernel-resident Mandatory Access Control + (MAC) 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. + + 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. + + 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 (/bin, + /lib) and configuration files + (/etc). The low side contains the + processes that interact with remote users (remote login + sessions, httpd) 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. + + 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 root process is + just as powerless as a low-level + non-root process. Since LOMAC + automatically places all network servers in the low part + of the system, this fact prevents compromised + root-privileged network servers from + harming the high-integrity part of the system. + + + + A Short Tour + + 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. + + + + Log in as root, from the + system console. + + + + Check to make sure that the LOMAC LKM is + loaded: + + # /sbin/kldstat | grep lomac.ko 5 1 + 0xc13e0000 c000 lomac.ko + + + + Look at the levels of your processes: + + # 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 + + Note that all your processes are running at level + 2—LOMAC's highest level of privilege. + + + + Look at the levels of your files. + (-Z shows levels.) + + # 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 ... + + 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. + + + + 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. + + # 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 + + Note that while /home 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. + + + + 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. + + # 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 + + Note that, although your shell + (csh 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 .cshrc 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. + + Level-2 processes have maximum privileges (like + root 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. + + 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 root, + were to cd to the malicious user's directory and type + ls, if the "." preceded /bin in + their path, they would accidentally execute the + malicious ls rather than + /bin/ls. This act would + effectively execute the malicious user's Trojan horse + program with root privileges, + perhaps to modify the login program or the + passwd file. + + 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-root 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. + + 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. + + # fg <output not included in document to save + space> q + + + + Create a test file. We'll use this test file to + demonstrate LOMAC's integrity protection later + on. + + # cat > /root/foo This file contains test data. + ^D + + + + tail -f + /var/log/messages + + Leave this running while you continue the tour. + It's output will contain LOMAC log messages as we + proceed. + + + + Switch to another virtual console and log in as a + normal user. Once logged in, examine the levels of + your processes: + + $ ps PID LVL TT STAT TIME COMMAND 742 1 + v7 S 0:00.48 -tcsh (tcsh) 750 1 v7 R+ + 0:00.05 ps + + 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 + root. You should see a log + message similar to: + + Oct 25 14:44:54 myhost + /boot/kernel/kernel: LOMAC: level-2 subject + p252g252u1002:login demoted to level 1 after reading + under "/usr/home" + + 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 + (tcsh in this case). The + shell starts at level 2, but LOMAC demotes it to level + 1 when it reads the user's .cshrc + 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. + + Our root shell from the start + of the tour remains at level-2 because LOMAC has set + all of root'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 + root/non-root + 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 + root identity. + + + + Test the above assertion that LOMAC does not give + any extra privileges to processes with + root identity. Switch back to the + normal user's shell and become + root. + + &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 + + Note that, despite the su, your + shell is still at level 1. LOMAC never increases the + level of a process. Now attempt to delete the + /root/foo file you created + earlier. + + # 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 + + Even though you are root, + LOMAC will not allow a level-1 process + (rm in this case) to delete a + level-2 file. You should see a log message similar to + this one in on the root virtual + console that is tailing /var/log/messages: + + Oct 25 14:50:52 myhost + /boot/kernel/kernel: LOMAC: level-1 proc p763g763u0:rm + denied delete to level-2 object under + "/" + + This concludes the short tour. + + + + + + LOMAC and Network Applications + + This section explains how LOMAC uses its demotion + behavior to ensure that all remote users and servers that + serve remote users (httpd, + ftpd, 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 root + privilege. It also discusses a few of the finer points + concerning LOMAC's protection scheme not already covered + in the Short Tour + section, above. The basic elements of LOMAC's integrity + protection scheme are summarized here: + + + + 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). + + + + 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. + + + + 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. + + + + 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. + + + + 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. + + + + 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. + + 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. + + 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. + + # 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 + + After httpd reads its first request from the network, + you should see a message similar to this one in + /var/log/messages: + + Oct 25 16:16:24 myhost /boot/kernel/kernel: + LOMAC: level-2 subject p369g368u65534:httpd demoted to + level 1 after reading from the network + + And running ps again will produce: + + 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 + + LOMAC demoted httpd process 369 as soon as it read its + first client request. + + + + LOMAC and Traditional UNIX Access Control + + 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. + + There are three main differences between the integrity + protection scheme implemented by LOMAC and traditional + UNIX security mechanisms: + + + + 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. + + + + 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 + root. The Trojan ls scenario in + the Short Tour + section describes one well-known example of this + vulnerability, and how LOMAC counters it. + + + + 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. + + + + + + Limits of LOMAC's Protection + + 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. + + 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 + root-privileged network server could, + for example, send kill signals to another level-1 + server. + + + 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. + + The dhclient application reads DHCP information from + the network and attempts to update the host's + /etc 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 /etc configuration files. + Although dangerous, dhclient's behavior is required for + the proper operation of some systems. + + 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 /etc + configuration files as it chooses. + + The FreeBSD version of LOMAC presently two flags for + processes, each implementing a specific flavor of + trust: + + + + + NONETDEMOTE + + + + LOMAC will not demote a processes after reading + from the network provided that it has this flag + set. + + + + + + NODEMOTE + + + + LOMAC will never demote a process that has this + flag set. + + + + + 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. + + LOMAC will set a process's + NONETDEMOTE or + NODEMOTE 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 policy_plm.h. + + If you create symlinks to env + named env-nonetdemote and + env-nodemote , executing env through + these symlinks will cause env and its child processes to + run with the NONETDEMOTE and + NODEMOTE flags, respectively. This + feature may be an aid to administration, particularly when + downloading and installing new software. + To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message