From owner-p4-projects Mon May 20 20:32:18 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 82BC937B407; Mon, 20 May 2002 20:30:31 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 18B0A37B415 for ; Mon, 20 May 2002 20:30:19 -0700 (PDT) Received: (from perforce@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g4L3UIT50010 for perforce@freebsd.org; Mon, 20 May 2002 20:30:18 -0700 (PDT) (envelope-from chris@freebsd.org) Date: Mon, 20 May 2002 20:30:18 -0700 (PDT) Message-Id: <200205210330.g4L3UIT50010@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: perforce set sender to chris@freebsd.org using -f From: Chris Costello Subject: PERFORCE change 11659 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=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 @@
LOMAC Operations Manual - + Fraser - + Tim - - + + - + Costello - + Chris - - + + - + Not yet published - + 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. - + 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. + 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. + 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. - + 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) - - K. J. Biba, "Integrity Considerations for Secure Computer - Systems," Electronic Systems Division, Hanscom Air Force Base, - Bedford, MA, April 1977, pages 27-31.BIB77 - - - - T. Fraser "LOMAC: Low Water-Mark Integrity Protection for - COTS Environments", Proceedings of the 2000 IEEE Symposium on - Security and Privacy, 2000. - - - - T. Fraser, "LOMAC: MAC You Can Live With", Proceedings of - the FREENIX Track: USENIX Annual Technical Conference, Boston, - Massachusetts, June, 2001. - - - 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. - + 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) + + K. J. Biba, "Integrity Considerations for Secure Computer + Systems," Electronic Systems Division, Hanscom Air Force Base, + Bedford, MA, April 1977, pages 27-31.BIB77 + + + + T. Fraser "LOMAC: Low Water-Mark Integrity Protection for + COTS Environments", Proceedings of the 2000 IEEE Symposium on + Security and Privacy, 2000. + + + + T. Fraser, "LOMAC: MAC You Can Live With", Proceedings of + the FREENIX Track: USENIX Annual Technical Conference, Boston, + Massachusetts, June, 2001. + + + 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. - + 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. + 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. - + 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: - + ::prompt.root; - /sbin/kldstat | grep lomac.ko - - 5 1 0xc13e0000 c000 lomac.ko + /sbin/kldstat | grep lomac.ko + + 5 1 0xc13e0000 c000 lomac.ko - + Look at the levels of your processes: - + ::prompt.root; - 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 - + 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. + 2—LOMAC's highest level of privilege. - - + + Look at the levels of your files. (-Z shows levels.) - + ::prompt.root; - 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 - + 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. + 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. - + user tfraser in the example; you'll have to use one of your own + users. + ::prompt.root; - 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 - + 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. + /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. - + in the background with ctrl-Z. Then run ps to look at your + processes. + ::prompt.root; - less /home/tfraser/.bash_history - - <output not included in document to save space> - ^Z - - Suspended ::prompt.root; - 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 - + less /home/tfraser/.bash_history + + <output not included in document to save space> + ^Z + + Suspended ::prompt.root; + 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. - + 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. - + 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 + 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. - /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. - + 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. - + protection scheme. Now that we've demonstrated how it works, + we're now done with less. Quit the less program. + ::prompt.root; - fg - - <output not included in document to save space> - q + 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 + 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. + 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: - + user. Once logged in, examine the levels of your + processes: + ::prompt.user; - ps - - PID LVL TT STAT TIME COMMAND 742 1 v7 S 0:00.48 -tcsh (tcsh) - 750 1 v7 R+ 0:00.05 ps - + 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: - + 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" - + 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. - + 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. + 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. - + extra privileges to processes with root identity. Switch back + to the normal user's shell and become root. + ::prompt.user; - su - - Password: ::prompt.root; - 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 - + su + + Password: ::prompt.root; + 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. - + 1. LOMAC never increases the level of a process. Now attempt to + delete the /root/foo file you created earlier. + ::prompt.root; - ls -lZ /root/foo - - -rw-r--r-- 1 root wheel 2 30 Oct 25 14:44 /root/foo - ::prompt.root; - rm /root/foo - - rm: /root/foo: Operation not permitted - + ls -lZ /root/foo + + -rw-r--r-- 1 root wheel 2 30 Oct 25 14:44 /root/foo + ::prompt.root; + 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: - + 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 "/" - + 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: - + 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). + (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. + 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. + 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. + 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. + 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. - + 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. - + 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. - + first request. Note that the httpd server is comprised of 5 + processes, all at level 2. + ::prompt.root; - 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 - + 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: - + 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 - + 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 - + /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. + 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. - + 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: - + 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. + 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 wellknown example of this vulnerability, - and how LOMAC counters it. + 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. - + 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. + 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. - - + 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 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