Date: Mon, 20 May 2002 20:30:18 -0700 (PDT) From: Chris Costello <chris@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 11659 for review Message-ID: <200205210330.g4L3UIT50010@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://people.freebsd.org/~peter/p4db/chv.cgi?CH=11659 Change 11659 by chris@chris_holly on 2002/05/20 20:29:54 Now that I've finally begun to learn to use xemacs and the PSGML tools, let's start by properly indenting this file. More fix-em-up's to come. Affected files ... ... //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/lomac/article.sgml#3 edit Differences ... ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/lomac/article.sgml#3 (text+ko) ==== @@ -2,693 +2,693 @@ <article> <articleinfo> <title>LOMAC Operations Manual</title> - + <authorgroup> <author> <surname>Fraser</surname> - + <firstname>Tim</firstname> - -<!-- affiliation-NAI Labs CBOSS Project-/affiliation --> + + <!-- affiliation-NAI Labs CBOSS Project-/affiliation --> </author> - + <author> <surname>Costello</surname> - + <firstname>Chris</firstname> - -<!-- affiliation-Safeport Network Services, NAI Labs CBOSS - Project</affiliation --> + + <!-- affiliation-Safeport Network Services, NAI Labs CBOSS + Project</affiliation --> </author> </authorgroup> - + <pubdate>Not yet published</pubdate> - + <abstract> <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 root daemons. LOMAC is - designed to be largely invisible to users, and largely painless - to administrators.</para> - + 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 largely 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> + 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> </abstract> </articleinfo> - + <sect1> <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> - + 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) - <footnote id="bib77" label="BIB77"> - <para>K. J. Biba, "Integrity Considerations for Secure Computer - Systems," Electronic Systems Division, Hanscom Air Force Base, - Bedford, MA, April 1977, pages 27-31.BIB77</para> - </footnote> - - <footnote id="fra00" label="FRA00"> - <para>T. Fraser "LOMAC: Low Water-Mark Integrity Protection for - COTS Environments", Proceedings of the 2000 IEEE Symposium on - Security and Privacy, 2000.</para> - </footnote> - - <footnote id="fra01" label="FRA01"> - <para>T. Fraser, "LOMAC: MAC You Can Live With", Proceedings of - the FREENIX Track: USENIX Annual Technical Conference, Boston, - Massachusetts, June, 2001.</para> - </footnote> - - 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> - + 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) + <footnote> + <para>K. J. Biba, "Integrity Considerations for Secure Computer + Systems," Electronic Systems Division, Hanscom Air Force Base, + Bedford, MA, April 1977, pages 27-31.BIB77</para> + </footnote> + + <footnote> + <para>T. Fraser "LOMAC: Low Water-Mark Integrity Protection for + COTS Environments", Proceedings of the 2000 IEEE Symposium on + Security and Privacy, 2000.</para> + </footnote> + + <footnote> + <para>T. Fraser, "LOMAC: MAC You Can Live With", Proceedings of + the FREENIX Track: USENIX Annual Technical Conference, Boston, + Massachusetts, June, 2001.</para> + </footnote> + + 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, 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.</para> - + 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, 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.</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 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.</para> + 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.</para> </sect1> - + <sect1> <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> - + 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 root, from the system console.</para> </listitem> - + <listitem> <para>Check to make sure that the LOMAC LKM is loaded:</para> - + <screen>::prompt.root; - <userinput>/sbin/kldstat | grep lomac.ko</userinput> - - 5 1 0xc13e0000 c000 lomac.ko</screen> + <userinput>/sbin/kldstat | grep lomac.ko</userinput> + + 5 1 0xc13e0000 c000 lomac.ko</screen> </listitem> - + <listitem> <para>Look at the levels of your processes:</para> - + <screen>::prompt.root; - <userinput>ps</userinput> - - 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> - + <userinput>ps</userinput> + + 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> + 2—LOMAC's highest level of privilege.</para> </listitem> - -<!-- XXX --> + + <!-- XXX --> <listitem> <para>Look at the levels of your files. (<literal>-Z</literal> shows levels.)</para> - + <screen>::prompt.root; - <userinput>ls -lZ</userinput> - - 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> - + <userinput>ls -lZ</userinput> + + 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> + 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> - + user tfraser in the example; you'll have to use one of your own + users.</para> + <screen>::prompt.root; - <userinput>ls -laZ /home/tfraser</userinput> - - 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> - + <userinput>ls -laZ /home/tfraser</userinput> + + 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> + <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> - + in the background with ctrl-Z. Then run ps to look at your + processes.</para> + <screen>::prompt.root; - <userinput>less /home/tfraser/.bash_history</userinput> - - <output not included in document to save space> - <userinput>^Z</userinput> - - Suspended ::prompt.root; - <userinput>ps</userinput> - - 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> - + <userinput>less /home/tfraser/.bash_history</userinput> + + <output not included in document to save space> + <userinput>^Z</userinput> + + Suspended ::prompt.root; + <userinput>ps</userinput> + + 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 (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.</para> - + 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.</para> + <para>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.</para> - + 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 root, were to cd to - the malicious user's directory and type ls, if the "." preceded + 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 + + <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 root privileges, perhaps to modify + the login program or The passwd file.</para> - <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 root privileges, perhaps to modify - the login program or The passwd 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-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.</para> - + 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.</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> - + protection scheme. Now that we've demonstrated how it works, + we're now done with less. Quit the less program.</para> + <screen>::prompt.root; - <userinput>fg</userinput> - - <output not included in document to save space> - q</screen> + <userinput>fg</userinput> + + <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. # cat > - /root/foo This file contains test data. ^D</para> + demonstrate LOMAC's integrity protection later on. # cat > + /root/foo This file contains test data. ^D</para> </listitem> - + <listitem> <para>tail -f /var/log/messages Leave this running while you - continue the tour. It's output will contain LOMAC log messages - as we proceed.</para> + 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> - + user. Once logged in, examine the levels of your + processes:</para> + <screen>::prompt.user; - <userinput>ps</userinput> - - PID LVL TT STAT TIME COMMAND 742 1 v7 S 0:00.48 -tcsh (tcsh) - 750 1 v7 R+ 0:00.05 ps</screen> - + <userinput>ps</userinput> + + 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 root. You should see a log message similar - to:</para> - + level 1. Why? Switch back to the virtual console where you are + logged in as root. 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> - + 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 (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.</para> - + 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.</para> + <para>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.</para> + 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.</para> </listitem> - + <listitem> <para>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.</para> - + extra privileges to processes with root identity. Switch back + to the normal user's shell and become root.</para> + <screen>::prompt.user; - <userinput>su</userinput> - - Password: ::prompt.root; - <userinput>ps</userinput> - - 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> - + <userinput>su</userinput> + + Password: ::prompt.root; + <userinput>ps</userinput> + + 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 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.</para> - + 1. LOMAC never increases the level of a process. Now attempt to + delete the /root/foo file you created earlier.</para> + <screen>::prompt.root; - <userinput>ls -lZ /root/foo</userinput> - - -rw-r--r-- 1 root wheel 2 30 Oct 25 14:44 /root/foo - ::prompt.root; - <userinput>rm /root/foo</userinput> - - rm: /root/foo: Operation not permitted</screen> - + <userinput>ls -lZ /root/foo</userinput> + + -rw-r--r-- 1 root wheel 2 30 Oct 25 14:44 /root/foo + ::prompt.root; + <userinput>rm /root/foo</userinput> + + rm: /root/foo: Operation not permitted</screen> + <para>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:</para> - + 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:</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> - + LOMAC: level-1 proc p763g763u0:rm denied delete to level-2 + object under "/"</programlisting> + <para>This concludes the short tour.</para> </listitem> </orderedlist> </sect1> - + <sect1> <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 - (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:</para> - + 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:</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> + (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> + 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> + 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> + 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> + 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> - + 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> - + 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> - + first request. Note that the httpd server is comprised of 5 + processes, all at level 2.</para> + <screen>::prompt.root; - <userinput>ps -U nobody</userinput> - - 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> - + <userinput>ps -U nobody</userinput> + + 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> - + 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> - + 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> - + /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> + client request.</para> </sect1> - + <sect1> <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> - + 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> - + 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> + 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 root. The Trojan ls scenario in the SHORT TOUR - section describes one wellknown example of this vulnerability, - and how LOMAC counters it.</para> + 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 wellknown 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> + 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> </sect1> - + <sect1> <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 - <footnoteref linkend="fra00" /> - - . 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> - -<!-- BIBLIO REFERENCE --> + 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 + <footnoteref>> + + . 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.</footnoteref></para> + + <!-- BIBLIO REFERENCE --> <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 root-privileged - network server could, for example, send kill signals to another - level-1 server.</para> - -<!-- BIBLIO REFERENCE --> + 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 >>> TRUNCATED FOR MAIL (1000 lines) <<< 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?200205210330.g4L3UIT50010>