From owner-p4-projects Wed May 22 17:54:20 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 1417937B401; Wed, 22 May 2002 17:53:04 -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 E1CFB37B40F for ; Wed, 22 May 2002 17:52:57 -0700 (PDT) Received: (from perforce@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g4N0qvg61955 for perforce@freebsd.org; Wed, 22 May 2002 17:52:57 -0700 (PDT) (envelope-from chris@freebsd.org) Date: Wed, 22 May 2002 17:52:57 -0700 (PDT) Message-Id: <200205230052.g4N0qvg61955@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: perforce set sender to chris@freebsd.org using -f From: Chris Costello Subject: PERFORCE change 11752 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=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 @@ 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. + 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. + 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. @@ -51,75 +51,78 @@ 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 + 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 - + 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) - - T. Fraser "LOMAC: Low Water-Mark Integrity Protection for - COTS Environments", Proceedings of the 2000 IEEE Symposium on - Security and Privacy, 2000. + + 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: MAC You Can Live With", Proceedings of - the FREENIX Track: USENIX Annual Technical Conference, Boston, - Massachusetts, June, 2001. + + T. Fraser "LOMAC: Low Water-Mark Integrity Protection + for COTS Environments", Proceedings of the 2000 IEEE + Symposium on Security and Privacy, 2000. - 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. + + 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 + 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. @@ -137,20 +140,16 @@ Check to make sure that the LOMAC LKM is loaded: - ::prompt.root; - /sbin/kldstat | grep lomac.ko - - 5 1 0xc13e0000 c000 lomac.ko + &prompt.root; /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 + &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 Note that all your processes are running at level 2—LOMAC's highest level of privilege. @@ -158,42 +157,38 @@ - Look at the levels of your files. (-Z shows levels.) + 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 + &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 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. - 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. + 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. - ::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 + &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 - 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. + 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. @@ -201,91 +196,80 @@ 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 + &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 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. + Level-2 processes have maximum privileges (like "root" + in standard UNIX). Level-1 processes have greatly reduced + privileges. For example, they cannot write to level-2 files, + or signal level-2 processes. When a level-2 process reads a + level-1 file, it puts itself at risk. The file may be a + Trojan horse or may contain data designed to cause buffer + overflows. Because of this risk, LOMAC demotes level-2 + processes that read level-1 files to level 1. Once at level + 1, these processes have insufficient privilege to harm + level-2 processes and files. Many cautious UNIX administrators avoid putting "." in their PATH environment variable, in order to avoid executing some Trojan horses. In standard UNIX, a malicious user might - give an attack program the same name as a commonly-used command - like ls. If the administrator, running as root, were to cd to - the malicious user's directory and type ls, if the "." preceded - - /bin - - in their path, they would accidentally execute the malicious - ls - - rather than - /bin/ls - - . This act would effectively execute the malicious user's - Trojan horse program with root privileges, perhaps to modify - the login program or The passwd file. + give an attack program the same name as a commonly-used + command like ls. If the administrator, running as root, were + to cd to the malicious user's directory and type ls, if the + "." preceded /bin in their path, they + would accidentally execute the malicious + ls rather than + /bin/ls . This act would effectively + execute the malicious user's Trojan horse program with root + privileges, perhaps to modify the login program or The + passwd file. This precaution is not required in a system running LOMAC. LOMAC considers the execution of a program to be - equivalent to a read (since the process reads the program file - in order to execute it). Since all non-root user's files are at - level 1, LOMAC would demote the process executing the Trojan - ls, just as it demoted less in our example, above. Once at - level 1, LOMAC would prevent the Trojan ls from modifying - level-2 files such as the login program or the passwd - file. + 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. - ::prompt.root; - fg - - <output not included in document to save space> - q + &prompt.root; 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. @@ -293,77 +277,69 @@ 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 + &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 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: 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. + All the getty programs that handle logins run at level + 2. When a user attempts to log in, they run the login + program, which also runs at level 2. Upon supplying the + proper password, the login program starts a shell for the + user (tcsh in this case). The shell starts at level 2, but + LOMAC demotes it to level 1 when it reads the user's .cshrc + file, just as it demoted the less program, above. Once the + user's shell is running at level 1, all of the programs + subsequently executed by the user will run at level 1, + also. Our root shell from the start of the tour remains at - level-2 because LOMAC has set all of root's files at level 2. A - level-2 process may read level-2 files without being demoted. - The user's shell is demoted because it reads the user's level-1 - files. LOMAC does not assign levels to processes based on the - user's root/non-root identity. LOMAC assigns levels to files by - starting the first process (init) at level 2, allowing child - processes to inherit their parent's level, and by demoting - processes that read level-1 files. LOMAC does not pay any - attention to user identity. Consequently, LOMAC is not - vulnerable to any of the traditional attacks on UNIX security - that involve obtaining root identity. + 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 + &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 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 - + &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 + &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 @@ -377,50 +353,52 @@ 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: + This section explains how LOMAC uses its demotion behavior + to ensure that all remote users and servers that serve remote + users (httpd, ftpd, etc.) run at level 1. At this level, + malicious remote users and compromised network servers can do + little harm to the level-2 part of the system, even if they have + root privilege. It also discusses a few of the finer points + concerning LOMAC's protection scheme not already covered in the + SHORT TOUR section, above. The basic elements of LOMAC's + integrity protection scheme are summarized here: LOMAC assigns every process, or named filesystem object - (file, named pipe, or bound UNIX-domain socket) a level: either - 1 (low integrity) or 2 (high integrity). + (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. + LOMAC assigns levels to filesystem objects based on + their location in the filesystem namespace. The mapping + between names and levels constitutes most of LOMAC's + "default policy", and is presently hardcoded into the LKM. + Once assigned, the levels of filesystem objects never + change. The first process (init) starts at level 2. All child processes inherit the level of their parent. Only when a - level-2 process reads from a level-1 object does LOMAC demote - the process to level 1. + level-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-1 processes have insufficient privilege to write + to level-2 objects or signal level-2 processes. This + protects the level-2 part of the system from malicious + interference. The combination of LOMAC's demotion behavior and its restrictions on the privileges of level-1 processes prevent malicious level-1 users from harming the level-2 part of the - system, even in cases where level-2 administrators accidentally - execute malicious user's Trojan horses. + system, even in cases where level-2 administrators + accidentally execute malicious user's Trojan horses. @@ -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. + 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. - ::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 + &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 After httpd reads its first request from the network, you should see a message similar to this one in @@ -471,10 +446,10 @@ 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. @@ -484,10 +459,10 @@ 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 @@ -497,35 +472,35 @@ 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. + 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. @@ -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 - > - - . 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. + 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. + scheme should grant a subject the minimum set of privileges + needed to do its job [SAL75]. Constraining a subject in this way + minimizes the amount of damage the subject can cause should it + become compromised. Low Water-Mark provides weaker constraints + than some more modern models. The LOMAC AND NETWORK APPLICATIONS + section describes how LOMAC protects the level-2 part of the + system by demoting network servers to level 1. Although LOMAC + will prevent a compromised level-1 network server from harming + the level-2 part of the system, LOMAC will not prevent such a + server from doing harm in the level-1 remainder of the system. A + compromised root-privileged network server could, for example, + send kill signals to another level-1 server. The second drawback of the Low Water-Mark MAC scheme is its @@ -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. + APPLICATIONS section, LOMAC protects the integrity of the + level-2 part of the system by demoting all applications which + read from the network to level 1. Once demoted, these + applications can no longer modify level-2 files. Although this + demotion and confinement prevents potentially-compromised + network applications provides useful protection, it also + prevents applications like dhclient from operating + properly. The dhclient application reads DHCP information from the - network and attempts to update the host's - /etc - - configuration files, accordingly. This is exactly the kind of - potentially-dangerous behavior that is prohibited by LOMAC; a - dhclient that LOMAC has demoted to level 1 cannot modify - /etc - - configuration files. Although dangerous, dhclient's behavior is - required for the proper operation of some systems. + network and attempts to update the host's + /etc configuration files, accordingly. This + is exactly the kind of potentially-dangerous behavior that is + prohibited by LOMAC; a dhclient that LOMAC has demoted to level + 1 cannot modify /etc configuration files. + Although dangerous, dhclient's behavior is required for the + proper operation of some systems. LOMAC must provide an exception to its policy in order to allow dhclient to run, and "trust" dhclient not to abuse this - exceptional privilege. LOMAC sets the special "NONETDEMOTE" flag on - all processes running the dhclient program. LOMAC will not demote a - process with this flag set when that process reads from the - network. This exception allows a level-2 dhclient to stay at level - 2 after reading DHCP information from the network, permitting it to - modify - /etc - - configuration files as it chooses. + exceptional privilege. LOMAC sets the special "NONETDEMOTE" flag + on all processes running the dhclient program. LOMAC will not + demote a process with this flag set when that process reads from + the network. This exception allows a level-2 dhclient to stay at + level 2 after reading DHCP information from the network, + permitting it to modify /etc configuration + files as it chooses. The FreeBSD version of LOMAC presently two flags for processes, each implementing a specific flavor of trust: @@ -630,65 +599,49 @@ 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. - LOMAC will set a process's - NONETDEMOTE - - or - NODEMOTE - - flag when that process executes a particular program, such as - dhclient. In addition, once a process has one of these flags set, - any children it subsequently creates will have the same flag set. - LOMAC maintains a short list mapping programs to process trust - flags. Eventually, that list will be shown here. However, since the - FreeBSD version of LOMAC is still under development, the membership - of the list is still fluid. The best reference is the LOMAC source - code, specifically - policy_plm.h - - . + LOMAC will set a process's NONETDEMOTE + or NODEMOTE flag when that process executes + a particular program, such as dhclient. In addition, once a + process has one of these flags set, any children it subsequently + creates will have the same flag set. LOMAC maintains a short + list mapping programs to process trust flags. Eventually, that + list will be shown here. However, since the FreeBSD version of + LOMAC is still under development, the membership of the list is + still fluid. The best reference is the LOMAC source code, + specifically policy_plm.h . - If you create symlinks to - env - - named - env-nonetdemote - - and - env-nodemote - - , executing env through these symlinks will cause env and its child - processes to run with the - NONETDEMOTE - - and - NODEMOTE - - flags, respectively. This feature may be an aid to administration, - particularly when downloading and installing new software. + If you create symlinks to env named + env-nonetdemote and + env-nodemote , executing env through these + symlinks will cause env and its child processes to run with the + NONETDEMOTE and + NODEMOTE flags, respectively. This feature + may be an aid to administration, particularly when downloading + and installing new software. SEE ALSO - + + 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. + 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message