From owner-p4-projects Tue Oct 22 19:30:40 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id EE52837B404; Tue, 22 Oct 2002 19:30:20 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AD5837B401 for ; Tue, 22 Oct 2002 19:30:20 -0700 (PDT) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7969443E42 for ; Tue, 22 Oct 2002 19:30:19 -0700 (PDT) (envelope-from chris@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.12.6/8.12.6) with ESMTP id g9N2ThmV055582 for ; Tue, 22 Oct 2002 19:29:43 -0700 (PDT) (envelope-from chris@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.12.6/8.12.6/Submit) id g9N2Tg9G055575 for perforce@freebsd.org; Tue, 22 Oct 2002 19:29:42 -0700 (PDT) Date: Tue, 22 Oct 2002 19:29:42 -0700 (PDT) Message-Id: <200210230229.g9N2Tg9G055575@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to chris@freebsd.org using -f From: Chris Costello Subject: PERFORCE change 19939 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://perforce.freebsd.org/chv.cgi?CH=19939 Change 19939 by chris@chris_nailabs on 2002/10/22 19:29:30 Remove the (largely LOMAC-centric) "TrustedBSD" section. Affected files ... .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#8 edit Differences ... ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#8 (text+ko) ==== @@ -944,750 +944,6 @@ - - - - - Chris - Costello - Written by - - - - - Trusted Operating System Features - - This section will give an overview of the features offered - by TrustedBSD. - - - Mandatory Access Control Framework - - This section will document the MAC framework from a user's - perspective. - - - Biba - - This section will document the Biba fixed-label MAC - policy. - - - - - - - - Tim - Fraser - - NAI Labs - - - - - Chris - Costello - - Safeport Network Services, NAI Labs - - - - - - Biba Low-Watermark Integrity Protection - - LOMAC is a loadable kernel module-based security - extension available on a number of UNIX kernels. LOMAC - provides Low Water-Mark Mandatory Access Control - functionality to protect the integrity of processes and data - from viruses, Trojan horses, malicious remote users, and - compromised root daemons. LOMAC is - designed to be virtually invisible to users, and largely - painless to administrators. - - This is the operations manual for LOMAC. It describes - LOMAC and the protection LOMAC provides. Please note that - the FreeBSD version of LOMAC is still under development. - Although enough functionality exists to provide some useful - protection, some features and fixes remain to be - implemented. The FreeBSD version of LOMAC should be used for - experimental purposes only at this time. - - - Introduction - - - MAC - - - Several projects have demonstrated that - kernel-resident Mandatory Access Control - (MAC) mechanisms can protect the - integrity of Free UNIX systems from malicious code and - users. However, implementations of these mechanisms have - traditionally required invasive kernel modifications, - sometimes coupled with supporting modifications of - user-space utilities, as well. This requirement has - hindered the adoption of MAC mechanisms in the mainstream - Free UNIX community. Adoption has been further discouraged - by the difficulty of starting small and evolving towards a - complete MAC solution - in general, the complete set of - extensive modifications must be made before MAC can - provide any useful protection. - - LOMAC is an attempt to make an easily-adoptable form - of MAC integrity protection available to the Free UNIX - community without the discouraging necessity of kernel - modifications. LOMAC implements a simple form of MAC - integrity protection based on Biba's Low Water-Mark model - in a Loadable Kernel Module (LKM) Although it trades off - some of the advanced MAC features found in traditional MAC - implementations, LOMAC provides useful integrity - protection without any modifications to the kernel, - applications, or their existing configurations. LOMAC is - designed to be compatible with existing software, and - ships with a one-size-fits-all default configuration. - LOMAC may be used to harden cur rently-deployed FreeBSD - systems simply by loading the LKM into the kernel shortly - after boot time. - - Once loaded, LOMAC divides the system into two - conceptual levels of integrity: high and low. The high - side contains all process and files that should be - protected from malicious code and remote users, including - the system binaries (/bin, - /lib) and configuration files - (/etc). The low side contains the - processes that interact with remote users (remote login - sessions, httpd) and the files - they download from the net (mail attachments). Low files - may contain viruses or Trojan Horses. Low processes take - input from remote users that may cause buffer overflows. - During run-time, LOMAC protects high files and processes - by preventing low processes from modifying or signalling - them. Thanks to is generic default configuration, LOMAC - handles the division of the system into high and low parts - automatically, without administrative direction. - - LOMAC does not override the existing FreeBSD - protection mechanisms. Instead, its permission checks are - done in addition to the existing ones—the kernel - permits an operation only if both the existing mechanisms - and LOMAC decide it should permit it. Unlike the existing - FreeBSD protection mechanisms, LOMAC makes decisions based - solely on integrity level, not on user identity. With - LOMAC, a low-level root process is - just as powerless as a low-level - non-root process. Since LOMAC - automatically places all network servers in the low part - of the system, this fact prevents compromised - root-privileged network servers from - harming the high-integrity part of the system. - - - - A Short Tour - - This section introduces LOMAC's major features. You - may follow these steps the first time you boot with LOMAC - running to ensure that your installation is - correct. - - - - Log in as root, from the - system console. - - - - Check to make sure that the LOMAC LKM is - loaded: - - # /sbin/kldstat | grep lomac.ko 5 1 - 0xc13e0000 c000 lomac.ko - - - - Look at the levels of your processes: - - # ps PID LVL TT STAT TIME COMMAND 251 2 - v6 Is 0:00.37 login -p root 650 2 v6 S - 0:00.56 -csh (csh) 665 2 v6 R+ 0:00.05 - ./ps - - Note that all your processes are running at level - 2—LOMAC's highest level of privilege. - - - - Look at the levels of your files. - (-Z shows levels.) - - # ls -lZ total 62 -rw-r--r-- 2 root wheel 2 - 802 Apr 21 2001 .cshrc -rw------- 1 root wheel 2 - 2973 Oct 12 09:41 .history -rw-r--r-- 1 root wheel - 2 142 Apr 21 2001 .klogin -rw-r--r-- 1 root wheel - 2 297 Apr 21 2001 .login ... - - Note that all your files are also at level 2. - Level-2 files are high-integrity—LOMAC assumes - that they contain no viruses or Trojan horses at boot - time, and limits the behavior of processes during - run-time to keep them that way. - - - - Look at the levels of a normal user's files. I'll - use the user tfraser in the example; you'll have to - use one of your own users. - - # ls -laZ /home/tfraser total 47 drwxr-xr-x 8 - tfraser staff 1 1024 Oct 25 14:30 . drwxr-xr-x 4 - root wheel 2 512 Aug 27 10:47 .. -rw------- 1 - tfraser staff 1 114 Aug 27 11:11 .Xauthority - -rw------- 1 tfraser staff 1 42 Oct 4 10:17 - .bash_history - - Note that while /home is - level 2 (high integrity), all of the user's files are - level 1 (low integrity). LOMAC assumes that any of the - user's files may be Trojan horses or contain - viruses. - - - - Examine one of the user's files with less, and put - less in the background with ctrl-Z. Then run ps to - look at your processes. - - # less /home/tfraser/.bash_history <output - not included in document to save space> ^Z - Suspended # ps PID LVL TT STAT TIME COMMAND 251 - 2 v6 Is 0:00.37 login -p root 650 2 v6 S - 0:01.28 -csh (csh) 733 1 v6 T 0:00.08 less - /home/tfraser/.bash_history 735 2 v6 R+ - 0:00.05 ./ps - - Note that, although your shell - (csh in my case) is still - at level 2, the process running less is at level 1. - Here's why: Processes generally inherit the level of - their parent. So, any process you start with your - level-2 shell will initially execute at level 2. The - less process was no exception - it began running at - level 2. However, the less process went on to read the - user's .cshrc file. This file is - a level-1 file—it contains low-integrity data. - Whenever LOMAC sees a level-2 process read a level-1 - file, LOMAC "demotes" the process. That is, it reduces - the process to level 1. - - Level-2 processes have maximum privileges (like - root in standard UNIX). Level-1 - processes have greatly reduced privileges. For - example, they cannot write to level-2 files, or signal - level-2 processes. When a level-2 process reads a - level-1 file, it puts itself at risk. The file may be - a Trojan horse or may contain data designed to cause - buffer overflows. Because of this risk, LOMAC demotes - level-2 processes that read level-1 files to level 1. - Once at level 1, these processes have insufficient - privilege to harm level-2 processes and files. - - Many cautious UNIX administrators avoid putting - "." in their PATH environment variable, in order to - avoid executing some Trojan horses. In standard UNIX, - a malicious user might give an attack program the same - name as a commonly-used command like ls. If the - administrator, running as root, - were to cd to the malicious user's directory and type - ls, if the "." preceded /bin in - their path, they would accidentally execute the - malicious ls rather than - /bin/ls. This act would - effectively execute the malicious user's Trojan horse - program with root privileges, - perhaps to modify the login program or the - passwd file. - - This precaution is not required in a system - running LOMAC. LOMAC considers the execution of a - program to be equivalent to a read (since the process - reads the program file in order to execute it). Since - all non-root user's files are at - level 1, LOMAC would demote the process executing the - Trojan ls, just as it demoted less in our example, - above. Once at level 1, LOMAC would prevent the Trojan - ls from modifying level-2 files such as the login - program or the passwd file. - - Demotion is a key part of the LOMAC's integrity - protection scheme. Now that we've demonstrated how it - works, we're now done with less. Quit the less - program. - - # fg <output not included in document to save - space> q - - - - Create a test file. We'll use this test file to - demonstrate LOMAC's integrity protection later - on. - - # cat > /root/foo This file contains test data. - ^D - - - - tail -f - /var/log/messages - - Leave this running while you continue the tour. - It's output will contain LOMAC log messages as we - proceed. - - - - Switch to another virtual console and log in as a - normal user. Once logged in, examine the levels of - your processes: - - $ ps PID LVL TT STAT TIME COMMAND 742 1 - v7 S 0:00.48 -tcsh (tcsh) 750 1 v7 R+ - 0:00.05 ps - - Note that as a normal user, all of your processes - are at level 1. Why? Switch back to the virtual - console where you are logged in as - root. You should see a log - message similar to: - - Oct 25 14:44:54 myhost - /boot/kernel/kernel: LOMAC: level-2 subject - p252g252u1002:login demoted to level 1 after reading - under "/usr/home" - - All the getty programs that handle logins run at - level 2. When a user attempts to log in, they run the - login program, which also runs at level 2. Upon - supplying the proper password, the login program - starts a shell for the user - (tcsh in this case). The - shell starts at level 2, but LOMAC demotes it to level - 1 when it reads the user's .cshrc - file, just as it demoted the less program, above. Once - the user's shell is running at level 1, all of the - programs subsequently executed by the user will run at - level 1, also. - - Our root shell from the start - of the tour remains at level-2 because LOMAC has set - all of root's files at level 2. A - level-2 process may read level-2 files without being - demoted. The user's shell is demoted because it reads - the user's level-1 files. LOMAC does not assign levels - to processes based on the user's - root/non-root - identity. LOMAC assigns levels to files by starting - the first process (init) at level 2, allowing child - processes to inherit their parent's level, and by - demoting processes that read level-1 files. LOMAC does - not pay any attention to user identity. Consequently, - LOMAC is not vulnerable to any of the traditional - attacks on UNIX security that involve obtaining - root identity. - - - - Test the above assertion that LOMAC does not give - any extra privileges to processes with - root identity. Switch back to the - normal user's shell and become - root. - - &prompt.user; su Password: # ps PID LVL TT STAT - TIME COMMAND 252 1 v7 Is 0:00.39 login -p - tfraser 751 1 v7 I 0:00.18 su 752 1 v7 S - 0:00.43 _su (csh) 755 1 v7 R+ 0:00.05 ps - - Note that, despite the su, your - shell is still at level 1. LOMAC never increases the - level of a process. Now attempt to delete the - /root/foo file you created - earlier. - - # ls -lZ /root/foo -rw-r--r-- 1 root wheel 2 - 30 Oct 25 14:44 /root/foo # rm /root/foo rm: - /root/foo: Operation not permitted - - Even though you are root, - LOMAC will not allow a level-1 process - (rm in this case) to delete a - level-2 file. You should see a log message similar to - this one in on the root virtual - console that is tailing /var/log/messages: - - Oct 25 14:50:52 myhost - /boot/kernel/kernel: LOMAC: level-1 proc p763g763u0:rm - denied delete to level-2 object under - "/" - - This concludes the short tour. - - - - - - LOMAC and Network Applications - - This section explains how LOMAC uses its demotion - behavior to ensure that all remote users and servers that - serve remote users (httpd, - ftpd, etc.) run at level 1. At - this level, malicious remote users and compromised network - servers can do little harm to the level-2 part of the - system, even if they have root - privilege. It also discusses a few of the finer points - concerning LOMAC's protection scheme not already covered - in the Short Tour - section, above. The basic elements of LOMAC's integrity - protection scheme are summarized here: - - - - LOMAC assigns every process, or named filesystem - object (file, named pipe, or bound UNIX-domain socket) - a level: either 1 (low integrity) or 2 (high - integrity). - - - - LOMAC assigns levels to filesystem objects based - on their location in the filesystem namespace. The - mapping between names and levels constitutes most of - LOMAC's "default policy", and is presently hardcoded - into the LKM. Once assigned, the levels of filesystem - objects never change. - - - - The first process (init) starts at level 2. All - child processes inherit the level of their parent. - Only when a level-2 process reads from a level-1 - object does LOMAC demote the process to level - 1. - - - - Level-1 processes have insufficient privilege to - write to level-2 objects or signal level-2 processes. - This protects the level-2 part of the system from - malicious interference. - - - - The combination of LOMAC's demotion behavior and - its restrictions on the privileges of level-1 - processes prevent malicious level-1 users from harming - the level-2 part of the system, even in cases where - level-2 administrators accidentally execute malicious - user's Trojan horses. - - - - In UNIX, network servers are generally started - automatically by the init process, or by one of its - children. With LOMAC, this arrangement guarantees that - network servers inherit the init process's level of 2. In - addition to demoting level-2 processes upon reading - level-1 files, LOMAC also demotes level-2 processes when - they read from a network interface. Consequently, LOMAC - demotes network server as soon as they read their first - client request from the network. Just as LOMAC assigns - appropriate levels to user shells based on their - file-reading behavior, not their user's identity, this - scheme allows LOMAC to demote network servers without - initially knowing which programs are network servers: - LOMAC simply allows the init program to start all of its - servers at level 2, and subsequently demotes those servers - which read from a network interface. - - LOMAC uses the same strategy to ensure that remote - users run at level 1: it demotes the remote login - (telnetd, rlogind) servers when they receive their first - login request, as described above. LOMAC's ability to - automatically determine the proper levels for users and - servers during runtime is the feature which allows it to - avoid site-specific configuration and ship with a - one-size-fits-all default policy. - - Here is an example of an httpd server before it reads - its first request. Note that the httpd server is comprised - of 5 processes, all at level 2. - - # ps -U nobody PID LVL TT STAT TIME COMMAND - 369 2 ?? I 0:00.03 /usr/local/sbin/httpd 370 2 - ?? I 0:00.03 /usr/local/sbin/httpd 371 2 ?? I - 0:00.03 /usr/local/sbin/httpd 372 2 ?? I 0:00.03 - /usr/local/sbin/httpd 373 2 ?? I 0:00.03 - /usr/local/sbin/httpd - - After httpd reads its first request from the network, - you should see a message similar to this one in - /var/log/messages: - - Oct 25 16:16:24 myhost /boot/kernel/kernel: - LOMAC: level-2 subject p369g368u65534:httpd demoted to - level 1 after reading from the network - - And running ps again will produce: - - PID LVL TT STAT TIME COMMAND - 369 1 ?? S 0:00.30 /usr/local/sbin/httpd 370 2 - ?? I 0:00.03 /usr/local/sbin/httpd 371 2 ?? I - 0:00.03 /usr/local/sbin/httpd 372 2 ?? I 0:00.03 - /usr/local/sbin/httpd 373 2 ?? I 0:00.03 - /usr/local/sbin/httpd 1572 2 ?? S 0:00.06 - /usr/local/sbin/httpd - - LOMAC demoted httpd process 369 as soon as it read its - first client request. - - - - LOMAC and Traditional UNIX Access Control - - LOMAC does not override the existing FreeBSD - protection mechanisms. Instead, its permission checks are - done in addition to the existing ones—the kernel - permits an operation only if both the existing mechanisms - and LOMAC decide the kernel should permit it. - - There are three main differences between the integrity - protection scheme implemented by LOMAC and traditional - UNIX security mechanisms: - - - - Traditional UNIX provides mechanisms by which - processes can increase their privileges by changing - their effective identities. Although UNIX systems can - be configured to prevent malicious users from - exploiting these mechanisms in most cases, they can - also be misconfigured, and good configurations can be - foiled by bugs in user-space application programs. - LOMAC provides no mechanism to allow a process to - increase its level. - - - - Traditional UNIX access control mechanisms are not - designed to prevent the flow of potentially dangerous - data from low-integrity objects to high-integrity - objects. That is, from files owned by one user to - those owned by another - even to those owned by - root. The Trojan ls scenario in - the Short Tour - section describes one well-known example of this - vulnerability, and how LOMAC counters it. - - - - Although many enhancements now exist, in its most - basic form traditional UNIX depends on easily defeated - authentication mechanisms to establish appropriate - initial privilege levels. LOMAC assigns privilege - levels to processes based on their reading behavior. - As described above, the effect of LOMAC's policy is to - give the highest level of privilege only local - administrative users, and the lowest level of - privilege to all others, regardless of identity. LOMAC - does not consider user identity; consequently, it does - not depend on authentication. - - - - - - Limits of LOMAC's Protection - - LOMAC embodies a trade-off between quality of MAC - protection and compatibility. LOMAC's primary goal is to - remain compatible with existing software while providing - some useful MAC integrity protection. The Low Water-Mark - MAC model supports this compatibility-first requirement. - However, it the quality of protection it provides is not - as great as that provided by more modern, less compatible, - models. This issue is discussed at length in. This section - presents the two well-known primary quality-of-protection - drawbacks of the Low Water-Mark model: its enforcement of - the principle of least privilege, and its reliance on - trusted applications. - - The first drawback of the Low Water-Mark MAC scheme - concerns the Principle of Least Privilege, which holds - that a good MAC scheme should grant a subject the minimum - set of privileges needed to do its job [SAL75]. - Constraining a subject in this way minimizes the amount of - damage the subject can cause should it become compromised. - Low Water-Mark provides weaker constraints than some more - modern models. The LOMAC AND NETWORK APPLICATIONS section - describes how LOMAC protects the level-2 part of the - system by demoting network servers to level 1. Although - LOMAC will prevent a compromised level-1 network server - from harming the level-2 part of the system, LOMAC will - not prevent such a server from doing harm in the level-1 - remainder of the system. A compromised - root-privileged network server could, - for example, send kill signals to another level-1 - server. - - - The second drawback of the Low Water-Mark MAC scheme - is its reliance on trusted applications. This reliance is - a feature of hierarchical models like Low Water-Mark - [BOE85]. The dhclient(8) client-side DHCP agent is a good - example of LOMAC's reliance on trusted applications: As - described in the LOMAC AND NETWORK APPLICATIONS section, - LOMAC protects the integrity of the level-2 part of the - system by demoting all applications which read from the - network to level 1. Once demoted, these applications can - no longer modify level-2 files. Although this demotion and - confinement prevents potentially-compromised network - applications provides useful protection, it also prevents - applications like dhclient from operating properly. - - The dhclient application reads DHCP information from - the network and attempts to update the host's - /etc configuration files, - accordingly. This is exactly the kind of - potentially-dangerous behavior that is prohibited by - LOMAC; a dhclient that LOMAC has demoted to level 1 cannot - modify /etc configuration files. - Although dangerous, dhclient's behavior is required for - the proper operation of some systems. - - LOMAC must provide an exception to its policy in order - to allow dhclient to run, and "trust" dhclient not to - abuse this exceptional privilege. LOMAC sets the special - "NONETDEMOTE" flag on all processes running the dhclient - program. LOMAC will not demote a process with this flag - set when that process reads from the network. This - exception allows a level-2 dhclient to stay at level 2 - after reading DHCP information from the network, - permitting it to modify /etc - configuration files as it chooses. - - The FreeBSD version of LOMAC presently two flags for - processes, each implementing a specific flavor of - trust: - - - - - NONETDEMOTE - - - - LOMAC will not demote a processes after reading - from the network provided that it has this flag - set. - - - - - - NODEMOTE - - - - LOMAC will never demote a process that has this - flag set. - - - - - Note that, although these flags allow level-2 - processes to escape demotion, they do not allow a level-1 - process to raise its level to 2. LOMAC does not provide - any such promotion mechanism. - - LOMAC will set a process's - NONETDEMOTE or - NODEMOTE flag when that process - executes a particular program, such as dhclient. In - addition, once a process has one of these flags set, any - children it subsequently creates will have the same flag - set. LOMAC maintains a short list mapping programs to - process trust flags. Eventually, that list will be shown - here. However, since the FreeBSD version of LOMAC is still - under development, the membership of the list is still - fluid. The best reference is the LOMAC source code, - specifically policy_plm.h. - - If you create symlinks to env - named env-nonetdemote and - env-nodemote , executing env through - these symlinks will cause env and its child processes to - run with the NONETDEMOTE and - NODEMOTE flags, respectively. This - feature may be an aid to administration, particularly when - downloading and installing new software. - - - - - Multi-Level Security - - This section will document the MLS policy. - - - - Type Enforcement - - This section will document the Type Enforcement - policy. - - - - BSD Extended - - This section will document the BSD Extended - policy. - - - - - Access Control Lists - - This section will document ACLs. - - - Configuring ACLs - - This section will include the commands and kernel - options necessary to enable ACLs on a given file - system. - - - - Examples Using ACLs - - This section will include a few hypothetical system - situations and appropriate ACL configuration for each - case. - - - - - POSIX.1e Capabilities - - This section will explain POSIX.1e Capabilities. - - - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message