Date: Wed, 22 May 2002 17:52:57 -0700 (PDT) From: Chris Costello <chris@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 11752 for review Message-ID: <200205230052.g4N0qvg61955@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://people.freebsd.org/~peter/p4db/chv.cgi?CH=11752 Change 11752 by chris@chris_holly on 2002/05/22 17:52:40 Re-wrap paragraphs, add an "XXX" or two. Affected files ... ... //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/lomac/article.sgml#4 edit Differences ... ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/lomac/article.sgml#4 (text+ko) ==== @@ -27,19 +27,19 @@ <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> + 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> + <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> </abstract> </articleinfo> @@ -51,75 +51,78 @@ </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 + 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> - <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> + 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>T. Fraser "LOMAC: Low Water-Mark Integrity Protection for - COTS Environments", Proceedings of the 2000 IEEE Symposium on - Security and Privacy, 2000.</para> + <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> - <para>T. Fraser, "LOMAC: MAC You Can Live With", Proceedings of - the FREENIX Track: USENIX Annual Technical Conference, Boston, - Massachusetts, June, 2001.</para> + <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> - 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> + <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> <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 + 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> @@ -137,20 +140,16 @@ <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> + <screen>&prompt.root; <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> + <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> <para>Note that all your processes are running at level 2—LOMAC's highest level of privilege.</para> @@ -158,42 +157,38 @@ <!-- XXX --> <listitem> - <para>Look at the levels of your files. (<literal>-Z</literal> shows levels.)</para> + <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> + <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> <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 + 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> + <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>::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> + <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> - <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> + <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> @@ -201,91 +196,80 @@ 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> + <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> <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> + <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> <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 - - <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> + 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> <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> + 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> - <screen>::prompt.root; - <userinput>fg</userinput> - - <output not included in document to save space> - q</screen> + <screen>&prompt.root; <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> @@ -293,77 +277,69 @@ 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> + <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> <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 + 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> + <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> <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> + <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> <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> - + <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> + &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 @@ -377,50 +353,52 @@ <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> + <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> <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> + <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> + 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> + <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> + system, even in cases where level-2 administrators + accidentally execute malicious user's Trojan horses.</para> </listitem> </orderedlist> @@ -431,34 +409,31 @@ 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> + 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> - <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> + <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> <para>After httpd reads its first request from the network, you should see a message similar to this one in @@ -471,10 +446,10 @@ <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> @@ -484,10 +459,10 @@ <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 @@ -497,35 +472,35 @@ <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> + 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> @@ -539,30 +514,28 @@ 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> + 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 --> <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> + 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 --> <para>The second drawback of the Low Water-Mark MAC scheme is its @@ -570,37 +543,33 @@ 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> + 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> + 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> + 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> @@ -630,65 +599,49 @@ </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 + 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>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> + <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> </sect1> <sect1> <title>SEE ALSO</title> - + + <!-- XXX --> <para>sec-arch(7), security(7) [BIB77] K. J. Biba, "Integrity Considerations for Secure Computer Systems," Electronic Systems Division, Hanscom Air Force Base, Bedford, MA, April 1977, pages 27-31. [BOE85] W. E. Boebert and R. Y. Kain, "A Practical - Alternative to Hierarchical Integrity Policies," Proceedings of the - 8th National Computer Security Conference, 1985. LWM and Trust: - pages 19-20. Assured Pipelines: pages 20-25. [FRA01] T. Fraser, - "LOMAC: MAC You Can Live With", Proceedings of the FREENIX Track: - USENIX Annual Technical Conference, Boston, Massachusetts, June, - 2001. [SAL75] J. H. Saltzer and M. D. Schroeder, "The Protection of - Information in Computer Systems," Proceedings of the IEEE Vol. - 63(9), September 1975, pages 1278-1308. Also summarized in Dorothy - E. Denning, "Cryptography and Data Security," Addison-Wesley, 1982, - page 206.</para> + Alternative to Hierarchical Integrity Policies," Proceedings of + the 8th National Computer Security Conference, 1985. LWM and + Trust: pages 19-20. Assured Pipelines: pages 20-25. [FRA01] T. + Fraser, "LOMAC: MAC You Can Live With", Proceedings of the + FREENIX Track: USENIX Annual Technical Conference, Boston, + Massachusetts, June, 2001. [SAL75] J. H. Saltzer and M. D. + Schroeder, "The Protection of Information in Computer Systems," + Proceedings of the IEEE Vol. 63(9), September 1975, pages + 1278-1308. Also summarized in Dorothy E. Denning, "Cryptography + and Data Security," Addison-Wesley, 1982, page 206.</para> </sect1> </article> 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?200205230052.g4N0qvg61955>