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