PERFORCE change 19939 for review
Chris Costello
chris at freebsd.org
Wed Oct 23 02:29:42 GMT 2002
http://perforce.freebsd.org/chv.cgi?CH=19939
Change 19939 by chris at 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 at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message
More information about the trustedbsd-cvs
mailing list