Re: SE Linux

To: russell@coker.com.au
Cc: Debian Devel <debian-devel@lists.debian.org>
Subject: Re: SE Linux
From: Tommi Virtanen <tv@tv.debian.net>
Date: Mon, 24 May 2004 21:33:32 +0300
Message-id: <[🔎] 40B23FFC.3040206@tv.debian.net>
In-reply-to: <[🔎] 200405171438.56017.russell@coker.com.au>
References: <[🔎] 200405171438.56017.russell@coker.com.au>

Russell Coker wrote:

We have had a few discussions about the state of SE Linux in Debian. Theyoften end up with people saying "I would like to help but don't think I knowenough about it".
Well now there's a way you can help out without knowing anything about SELinux. The selinux-doc package won't build due to problems with running jadeon sgml files. Someone who knows about such things can help the SE Linuxproject without knowing anything about SE Linux or computer security.
http://www.coker.com.au/selinux-doc/

Above is the URL for the relevant files.
If you can solve this problem then please take over the package. Anyone whocan fix this problem is better qualified to maintain the package than I am.


Why not work around problems in obsolete tools by modernizing the input?

Here's a proof-of-concept patch that makes the policy/*.sgml files XML
and switches toolchains. Not very clean, but it works.

Install atleast xsltproc, docbook-xsl, db2latex-xsl and pdflatex to make
it work.

As I renamed the files, and patch can't handle that, first run
for a in policy/*.sgml; do mv -i "$a" "${a%.sgml}.xml"; done
and then apply the patch.


If you (and upstream) like the approach, I can help/do more work.

diff -Naur selinux-doc-1.12.orig/policy/Makefile selinux-doc-1.12/policy/Makefile
--- selinux-doc-1.12.orig/policy/Makefile	2004-02-26 22:36:47.000000000 +0200
+++ selinux-doc-1.12/policy/Makefile	2004-05-24 21:24:57.000000000 +0300
@@ -1,32 +1,23 @@
-TOP     := main.sgml
-ALL     := $(wildcard *.sgml)
+TOP     := main.xml
+ALL     := $(wildcard *.xml)
 
-PS	:=	$(patsubst %.sgml, %.ps, $(TOP))
-PDF	:=	$(patsubst %.sgml, %.pdf, $(TOP))
-HTML    :=      $(patsubst %.sgml, %, $(TOP))
-DVI	:=	$(patsubst %.sgml, %.dvi, $(TOP))
-AUX	:=	$(patsubst %.sgml, %.aux, $(TOP))
-TEX	:=	$(patsubst %.sgml, %.tex, $(TOP))
-LOG	:=	$(patsubst %.sgml, %.log, $(TOP))
-OUT	:=	$(patsubst %.sgml, %.out, $(TOP))
+PDF	:=	$(patsubst %.xml, %.pdf, $(TOP))
+HTML    :=      $(patsubst %.xml, %.html, $(TOP))
 
-all: $(PS) $(HTML) $(PDF)
+all: $(PDF) $(HTML)
 
-$(PS): $(ALL) custom.dsl
-	jw -f docbook -d custom.dsl -b ps $(TOP)
-
-$(PDF): $(ALL) custom.dsl
-	jw -f docbook -d custom.dsl -b pdf $(TOP)
-
-$(HTML): $(ALL)
-	-$(RM) -r $@
-	db2html $(TOP)
-	if [ ! -z "$(JPG-$@)" ]; then cp $(JPG-$@) $@; fi
-
-clean:
-	-$(RM) core *~
-	-$(RM) $(DVI) $(AUX) $(TEX) $(LOG) $(OUT)
-
-mrproper: clean
-	-$(RM) $(PS) $(PDF)
-	-$(RM) -r $(HTML)
+%.tex: %.xml driver-latex.xsl $(ALL)
+	xsltproc --nonet driver-latex.xsl $< >$@.tmp
+	mv $@.tmp $@
+
+%.pdf: %.tex
+	test -d $@.tmp || mkdir $@.tmp
+	cp $^ $@.tmp
+	cd $@.tmp && pdflatex --interaction batchmode $<
+	cd $@.tmp && makeindex $<
+	cd $@.tmp && pdflatex --interaction batchmode $<
+	mv $@.tmp/$@ $@
+
+%.html: %.xml driver-xhtml.xsl $(ALL)
+	xsltproc --nonet driver-xhtml.xsl $< >$@.tmp
+	mv $@.tmp $@
diff -Naur selinux-doc-1.12.orig/policy/apps.xml selinux-doc-1.12/policy/apps.xml
--- selinux-doc-1.12.orig/policy/apps.xml	2004-02-26 22:36:47.000000000 +0200
+++ selinux-doc-1.12/policy/apps.xml	2004-05-24 21:12:31.000000000 +0300
@@ -16,7 +16,7 @@
 transition to an appropriate security context for user processes.  The
 appropriate security context for a user session or cron job is
 determined based on a combination of the security policy and default
-configuration files, as described in <xref linkend="appconfig">, or
+configuration files, as described in <xref linkend="appconfig"/>, or
 can optionally be explicitly specified by the user in the case of
 <filename>login</filename>.  The transition is performed using the
 <function>execve_secure</function> system call.  An explicit
@@ -32,7 +32,7 @@
 determines the new terminal context based on the user process context
 and the original terminal context.  Rules for terminal relabeling can
 be specified in the policy configuration via the TE change rules, as
-discussed in <xref linkend="techange">.  When the session ends, the
+discussed in <xref linkend="techange"/>.  When the session ends, the
 daemons relabel the terminal to its original context.
 </para>
 
@@ -95,7 +95,7 @@
 different role within a user session.  It obtains the default domain
 for the new role from the <filename>default_type</filename>
 application configuration file described in <xref
-linkend="appconfig">.  Alternatively, the user can explicitly specify
+linkend="appconfig"/>.  Alternatively, the user can explicitly specify
 the new domain on the command line.  The <command>newrole</command>
 program requires the user to reauthenticate to ensure that role
 changes only occur with user consent.  The authentication is based on
@@ -114,7 +114,7 @@
 identity, role, and domain when the scripts are run manually by an
 administrator.  The program obtains the security context from the
 <filename>initrc_context</filename> application configuration file
-described in <xref linkend="appconfig">.  As with
+described in <xref linkend="appconfig"/>.  As with
 <command>newrole</command>, this program requires the user to
 reauthenticate to ensure that such transitions only occur with the
 consent of the user.  This program runs in the
@@ -134,7 +134,7 @@
 <para>
 The <command>setfiles</command> and <command>chcon</command> utilities
 can be used to change the security context of a file.  These utilities
-were discussed in <xref linkend="fileconapply">.
+were discussed in <xref linkend="fileconapply"/>.
 </para>
 
 <para>
diff -Naur selinux-doc-1.12.orig/policy/arch.xml selinux-doc-1.12/policy/arch.xml
--- selinux-doc-1.12.orig/policy/arch.xml	2004-02-26 22:36:47.000000000 +0200
+++ selinux-doc-1.12/policy/arch.xml	2004-05-24 21:08:23.000000000 +0300
@@ -2,10 +2,10 @@
 
 <para>
 The Flask operating system security architecture provides flexible
-support for mandatory access control (MAC) policies<citation><XRef
-LinkEnd="SpencerUsenixSec99"></citation>.  The SELinux implementation
-of the Flask architecture is described in <citation><XRef
-LinkEnd="LoscoccoFreenix01"></citation>.  This section discusses
+support for mandatory access control (MAC) policies<citation><xref
+linkend="SpencerUsenixSec99"/></citation>.  The SELinux implementation
+of the Flask architecture is described in <citation><xref
+linkend="LoscoccoFreenix01"/></citation>.  This section discusses
 concepts defined by the Flask architecture that are important to
 configuring the SELinux policy.  It then discusses definitions
 specified by the Flask architecture that are used by both
@@ -137,11 +137,11 @@
 
 <para>
 The meaning of the security classes and access vector permissions in
-the original SELinux implementation was described in <citation><XRef
-LinkEnd="LoscoccoNSATR01"></citation> and <citation><XRef
-LinkEnd="LoscoccoFreenix01"></citation>.  Changes made for the
-LSM-based SELinux implementation are described in <citation><XRef
-LinkEnd="SmalleyModuleTR01"></citation>.
+the original SELinux implementation was described in <citation><xref
+linkend="LoscoccoNSATR01"/></citation> and <citation><xref
+linkend="LoscoccoFreenix01"/></citation>.  Changes made for the
+LSM-based SELinux implementation are described in <citation><xref
+linkend="SmalleyModuleTR01"/></citation>.
 </para>
 
 <para>
@@ -151,11 +151,11 @@
 These files are installed into
 <filename>/usr/local/selinux/flask</filename> and are used when the
 example policy configuration is compiled.  The Flask configuration
-files are listed in <xref linkend="flaskconfigtable">.
+files are listed in <xref linkend="flaskconfigtable"/>.
 
-<table id="flaskconfigtable" frame=all>
+<table id="flaskconfigtable" frame="all">
 <title>Architecture Configuration Files</title>
-<tgroup cols=2 align=left>
+<tgroup cols="2" align="left">
 <thead>
 <row>
     <entry>Filename</entry>
diff -Naur selinux-doc-1.12.orig/policy/biblio.xml selinux-doc-1.12/policy/biblio.xml
--- selinux-doc-1.12.orig/policy/biblio.xml	2004-02-26 22:36:47.000000000 +0200
+++ selinux-doc-1.12/policy/biblio.xml	2004-05-24 21:08:45.000000000 +0300
@@ -3,14 +3,14 @@
 
 <biblioentry id="BoebertNCSC85">
   <abbrev>BoebertNCSC1985</abbrev>
-  <biblioset relation=article>
+  <biblioset relation="article">
     <authorgroup>
       <author><firstname>W.</firstname><surname>Boebert</surname></author>
       <author><firstname>R.</firstname><surname>Kain</surname></author>
     </authorgroup>
     <title>A Practical Alternative to Hierarchical Integrity Policies</title>
   </biblioset>
-  <biblioset relation=journal>
+  <biblioset relation="journal">
     <title>Proceedings of the Eighth National Computer Security Conference</title>
     <pubdate>1985</pubdate>
   </biblioset>
@@ -18,14 +18,14 @@
 
 <biblioentry id="FerraioloNCSC92">
   <abbrev>FerraioloNCSC1992</abbrev>
-  <biblioset relation=article>
+  <biblioset relation="article">
     <authorgroup>
       <author><firstname>David</firstname><surname>Ferraiolo</surname></author>
       <author><firstname>Richard</firstname><surname>Kuhn</surname></author>
     </authorgroup>
     <title>Role-Based Access Controls</title>
   </biblioset>
-  <biblioset relation=journal>
+  <biblioset relation="journal">
     <title>Proceedings of the 15th National Computer Security Conference</title>
     <pubdate>October 1992</pubdate>
   </biblioset>
@@ -33,14 +33,14 @@
 
 <biblioentry id="LoscoccoFreenix01">
   <abbrev>LoscoccoFreenix2001</abbrev>
-  <biblioset relation=article>
+  <biblioset relation="article">
     <authorgroup>
       <author><firstname>Peter</firstname><surname>Loscocco</surname></author>
       <author><firstname>Stephen</firstname><surname>Smalley</surname></author>
     </authorgroup>
     <title>Integrating Flexible Support for Security Policies into the Linux Operating System</title>
   </biblioset>
-  <biblioset relation=journal>
+  <biblioset relation="journal">
     <title>Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference</title>
     <publisher>
       <publishername>The USENIX Association</publishername>
@@ -51,14 +51,14 @@
 
 <biblioentry id="LoscoccoOLS01">
   <abbrev>LoscoccoOLS2001</abbrev>
-  <biblioset relation=article>
+  <biblioset relation="article">
     <authorgroup>
       <author><firstname>Peter</firstname><surname>Loscocco</surname></author>
       <author><firstname>Stephen</firstname><surname>Smalley</surname></author>
     </authorgroup>
     <title>Meeting Critical Security Objectives with Security-Enhanced Linux</title>
   </biblioset>
-  <biblioset relation=journal>
+  <biblioset relation="journal">
     <title>Proceedings of the 2001 Ottawa Linux Symposium</title>
     <pubdate>July 2001</pubdate>
   </biblioset>
@@ -66,14 +66,14 @@
 
 <biblioentry id="LoscoccoNSATR01">
   <abbrev>LoscoccoNSATR2001</abbrev>
-  <biblioset relation=article>
+  <biblioset relation="article">
     <authorgroup>
       <author><firstname>Peter</firstname><surname>Loscocco</surname></author>
       <author><firstname>Stephen</firstname><surname>Smalley</surname></author>
     </authorgroup>
     <title>Integrating Flexible Support for Security Policies into the Linux Operating System</title>
   </biblioset>
-  <biblioset relation=journal>
+  <biblioset relation="journal">
     <title>NSA Technical Report</title>
     <pubdate>February 2001</pubdate>
   </biblioset>
@@ -81,14 +81,14 @@
 
 <biblioentry id="SmalleyNAITR01">
   <abbrev>SmalleyNAITR2001</abbrev>
-  <biblioset relation=article>
+  <biblioset relation="article">
     <authorgroup>
       <author><firstname>Stephen</firstname><surname>Smalley</surname></author>
       <author><firstname>Timothy</firstname><surname>Fraser</surname></author>
     </authorgroup>
     <title>A Security Policy Configuration for the Security-Enhanced Linux</title>
   </biblioset>
-  <biblioset relation=journal>
+  <biblioset relation="journal">
     <title>NAI Labs Technical Report</title>
     <pubdate>February 2001</pubdate>
   </biblioset>
@@ -96,7 +96,7 @@
 
 <biblioentry id="SmalleyModuleTR01">
   <abbrev>SmalleyModuleTR2001</abbrev>
-  <biblioset relation=article>
+  <biblioset relation="article">
     <authorgroup>
       <author><firstname>Stephen</firstname><surname>Smalley</surname></author>
       <author><firstname>Chris</firstname><surname>Vance</surname></author>
@@ -104,7 +104,7 @@
     </authorgroup>
     <title>Implementing SELinux as a Linux Security Module</title>
   </biblioset>
-  <biblioset relation=journal>
+  <biblioset relation="journal">
     <title>NAI Labs Report #01-043</title>
     <pubdate>December 2001</pubdate>
   </biblioset>
@@ -112,7 +112,7 @@
 
 <biblioentry id="SpencerUsenixSec99">
   <abbrev>SpencerUsenixSec1999</abbrev>
-  <biblioset relation=article>
+  <biblioset relation="article">
     <authorgroup>
       <author><firstname>Ray</firstname><surname>Spencer</surname></author>
       <author><firstname>Stephen</firstname><surname>Smalley</surname></author>
@@ -123,7 +123,7 @@
     </authorgroup>
     <title>The Flask Security Architecture:  System Support for Diverse Security Policies</title>
   </biblioset>
-  <biblioset relation=journal>
+  <biblioset relation="journal">
     <title>Proceedings of the Eighth USENIX Security Symposium</title>
     <publisher>
       <publishername>The USENIX Association</publishername>
diff -Naur selinux-doc-1.12.orig/policy/driver-latex.xsl selinux-doc-1.12/policy/driver-latex.xsl
--- selinux-doc-1.12.orig/policy/driver-latex.xsl	1970-01-01 02:00:00.000000000 +0200
+++ selinux-doc-1.12/policy/driver-latex.xsl	2004-05-24 21:22:14.000000000 +0300
@@ -0,0 +1,12 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version='1.0'>
+    <xsl:import href="http://db2latex.sourceforge.net/xsl/docbook.xsl"/>
+
+    <xsl:output method="text" encoding="UTF-8" indent="yes"/>
+
+    <xsl:variable name="l10n.gentext.default.language">en</xsl:variable>
+    <xsl:variable name="latex.documentclass.article">a4paper,10pt</xsl:variable>
+    <xsl:variable name="latex.use.parskip">1</xsl:variable>
+
+    <xsl:variable name="latex.inputenc">utf8</xsl:variable>
+</xsl:stylesheet>
diff -Naur selinux-doc-1.12.orig/policy/driver-xhtml.xsl selinux-doc-1.12/policy/driver-xhtml.xsl
--- selinux-doc-1.12.orig/policy/driver-xhtml.xsl	1970-01-01 02:00:00.000000000 +0200
+++ selinux-doc-1.12/policy/driver-xhtml.xsl	2004-05-24 21:23:18.000000000 +0300
@@ -0,0 +1,5 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version='1.0'>
+    <xsl:import href="/usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl"/>
+
+</xsl:stylesheet>
diff -Naur selinux-doc-1.12.orig/policy/examples.xml selinux-doc-1.12/policy/examples.xml
--- selinux-doc-1.12.orig/policy/examples.xml	2004-02-26 22:36:47.000000000 +0200
+++ selinux-doc-1.12/policy/examples.xml	2004-05-24 21:09:27.000000000 +0300
@@ -9,8 +9,8 @@
 <sect2 id="adduser"><title>Adding Users</title>
 <para>
 When a user is added to the system, the policy may need to be updated
-to recognize the user.  As discussed in <xref linkend="identitymodel">
-and <xref linkend="userlang">, it may be appropriate to simply map the
+to recognize the user.  As discussed in <xref linkend="identitymodel"/>
+and <xref linkend="userlang"/>, it may be appropriate to simply map the
 new user to the generic <constant>user_u</constant> user identity
 if the new user only requires unprivileged access and does not need
 to be separated from other such users by the policy.  In that case,
@@ -79,7 +79,7 @@
 <para>
 The audit messages should be carefully reviewed to determine whether
 the denied permission should be allowed via a TE
-allow rule (described in <xref linkend="teav">).
+allow rule (described in <xref linkend="teav"/>).
 The contributed <command>scripts/newrules.pl</command> script provides
 an example of how to automatically convert the audit messages to TE
 allow rules that grant the denied permissions,
@@ -104,15 +104,15 @@
 to access these files.  A better approach would be to define a
 separate domain for the <filename>logrotate</filename> program that
 has these permissions. This approach is discussed further in <xref
-linkend="adddomain">.
+linkend="adddomain"/>.
 </para>
 
 <para>
 Not all permission denials can be solved simply through modifying the
 TE configuration.  It may be necessary to modify the RBAC
-configuration (described in <xref linkend="rbaclang">) or the
+configuration (described in <xref linkend="rbaclang"/>) or the
 constraints configuration (described in <xref
-linkend="constraintlang">) as well.  In the example policy, these
+linkend="constraintlang"/>) as well.  In the example policy, these
 configurations are relevant for the process transition permission when
 the role or user identity changes and for the file create or relabel
 permissions when the user identity of the file differs from the
@@ -154,7 +154,7 @@
 type for the domain.  This relabeling can be performed either using
 <command>chcon</command> or by updating
 the file contexts configuration and running <command>make
-relabel</command>, as discussed in <xref linkend="fileconapply">.  If
+relabel</command>, as discussed in <xref linkend="fileconapply"/>.  If
 a process is already running the program, the administrator must then
 restart the process in order to place it into the domain, typically
 using <command>run_init</command> for system processes.
@@ -185,9 +185,9 @@
 -e --context</command>.  These system processes should either be
 disabled or placed into an appropriate domain.  This may simply
 involve adding the program to an existing domain, as discussed in
-<xref linkend="addprogram">, or it may require creating a new domain.
+<xref linkend="addprogram"/>, or it may require creating a new domain.
 The administrator may also discover that new domains are needed 
-to address denied permissions, as discussed in <xref linkend="addperms">,
+to address denied permissions, as discussed in <xref linkend="addperms"/>,
 for system processes or user programs.  New domains are also needed
 when new roles are defined.
 </para>
@@ -200,16 +200,16 @@
 the <filename>policy/domains/program/logrotate.te</filename> file for
 the <filename>logrotate</filename> program will be discussed.  The
 need for a separate domain for the <filename>logrotate</filename>
-program was introduced in <xref linkend="addperms">.  The domain
+program was introduced in <xref linkend="addperms"/>.  The domain
 definition begins by declaring the domain and its executable type
-using type declaration rules (described in <xref linkend="tedecl">),
+using type declaration rules (described in <xref linkend="tedecl"/>),
 as shown below:
 <programlisting>
 type logrotate_t, domain, privowner;
 type logrotate_exec_t, file_type, sysadmfile, exec_type;
 </programlisting>
 To grant the new domain permissions to many common operations, the 
-<constant>every_domain</constant> macro (described in <xref linkend="teavmacros"> in <xref linkend="teav">) can be used as shown below:
+<constant>every_domain</constant> macro (described in <xref linkend="teavmacros"/> in <xref linkend="teav"/>) can be used as shown below:
 <programlisting>
 every_domain(logrotate_t)
 </programlisting>
@@ -222,7 +222,7 @@
 If the program is known to create files in shared directories, e.g.
 <filename>/tmp</filename> files, then the administrator can declare
 types for these files and file type transition rules (described in
-<xref linkend="telabel">).  An example type declaration and file type
+<xref linkend="telabel"/>).  An example type declaration and file type
 transition rule for temporary files created by
 <filename>logrotate</filename> is shown below:
 <programlisting>
@@ -241,7 +241,7 @@
 To cause the domain to be entered automatically from system cron jobs
 and from administrator shells when <filename>logrotate</filename> is
 executed, domain transition rules (described in <xref
-linkend="telabel">) should be added for the appropriate domains.  These
+linkend="telabel"/>) should be added for the appropriate domains.  These
 rules can either be placed in the new domain's <filename>.te</filename>
 file or in the files for the source domains.  Typically, if the source
 domain transitions to many different domains (e.g. every daemon or many
@@ -258,7 +258,7 @@
 <para>
 After providing a minimal definition of the domain and transitions
 into the domain, the administrator should authorize roles for the
-domain.  Role declarations (described in <xref linkend="roledecl">)
+domain.  Role declarations (described in <xref linkend="roledecl"/>)
 can be placed either in the domain's <filename>.te</filename> file or
 in the <filename>policy/rbac</filename> file.  The former approach is
 preferable in order to encapsulate the domain's definition.  Role
@@ -289,8 +289,8 @@
 to discover whether additional permissions are required.  If the
 program is to be run as a system process, the administrator should use
 <command>run_init</command> to start it, as discussed in <xref
-linkend="newutils">.  If additional permissions are required, then the
-steps in <xref linkend="addperms"> can be followed to complete the domain.
+linkend="newutils"/>.  If additional permissions are required, then the
+steps in <xref linkend="addperms"/> can be followed to complete the domain.
 </para>
 </sect2>
 
@@ -299,8 +299,8 @@
 New types can be created to provide distinct protection for specific
 objects.  An administrator may also discover that new types are needed
 to address denied permissions, as discussed in <xref
-linkend="addperms">.  To create a new type, the administrator should
-first add a type declaration (described in <xref linkend="tedecl">) to
+linkend="addperms"/>.  To create a new type, the administrator should
+first add a type declaration (described in <xref linkend="tedecl"/>) to
 the TE configuration.  If the type is associated with a particular
 domain, then the declaration should be placed in the domain's
 <filename>.te</filename> file.  If the type is a general type, then
@@ -311,7 +311,7 @@
 <para>
 If automatic transitions to this type are desired, then the
 administrator should define type transition (described in <xref
-linkend="telabel">) rules for the appropriate domains.  The
+linkend="telabel"/>) rules for the appropriate domains.  The
 administrator should add appropriate TE allow rules to the TE
 configuration to permit authorized domains to access the type.  The
 administrator can then build and reload the policy via <command>make
diff -Naur selinux-doc-1.12.orig/policy/intro.xml selinux-doc-1.12/policy/intro.xml
--- selinux-doc-1.12.orig/policy/intro.xml	2004-02-26 23:34:40.000000000 +0200
+++ selinux-doc-1.12/policy/intro.xml	2004-05-24 21:09:41.000000000 +0300
@@ -3,8 +3,8 @@
 <para>
 NSA Security-Enhanced Linux (SELinux) is an implementation of a
 flexible and fine-grained mandatory access control (MAC) architecture
-called Flask in the Linux kernel<citation><XRef
-LinkEnd="LoscoccoFreenix01"></citation>.  SELinux can enforce an
+called Flask in the Linux kernel<citation><xref
+linkend="LoscoccoFreenix01"/></citation>.  SELinux can enforce an
 administratively-defined security policy over all processes and
 objects in the system, basing decisions on labels containing a variety
 of security-relevant information.  The architecture provides
@@ -19,28 +19,28 @@
 <para>
 To demonstrate the architecture, SELinux provides an example security
 server that implements a combination of Type Enforcement
-(TE)<citation><XRef LinkEnd="BoebertNCSC85"></citation> and Role-Based
-Access Control (RBAC)<citation><XRef
-LinkEnd="FerraioloNCSC92"></citation>.  These two security models also
+(TE)<citation><xref linkend="BoebertNCSC85"/></citation> and Role-Based
+Access Control (RBAC)<citation><xref
+linkend="FerraioloNCSC92"/></citation>.  These two security models also
 provide significant flexibility through a set of policy configuration
 files.  An example security policy configuration was developed to
 demonstrate how SELinux can be used to meet certain security goals and
-to provide a starting point for users <citation><XRef
-LinkEnd="SmalleyNAITR01"></citation><citation><XRef
-LinkEnd="LoscoccoOLS01"></citation>.
+to provide a starting point for users <citation><xref
+linkend="SmalleyNAITR01"/></citation><citation><xref
+linkend="LoscoccoOLS01"/></citation>.
 </para>
 
 <para>
 This technical report describes how to configure the SELinux security
-policy for the example security server.  <xref linkend="arch">
+policy for the example security server.  <xref linkend="arch"/>
 explains concepts defined by the Flask architecture that are important
-to configuring the policy.  <xref linkend="model"> describes the
+to configuring the policy.  <xref linkend="model"/> describes the
 security model implemented by the example security server.  The policy
 language and the example policy configuration are described in <xref
-linkend="lang">.  <xref linkend="build"> explains how the policy is
+linkend="lang"/>.  <xref linkend="build"/> explains how the policy is
 built and applied to the system.  Security-aware applications and
-their configurations are discussed in <xref linkend="apps">.  <xref
-linkend="examples"> describes how to customize the policy for various
+their configurations are discussed in <xref linkend="apps"/>.  <xref
+linkend="examples"/> describes how to customize the policy for various
 purposes.
 </para>
 
diff -Naur selinux-doc-1.12.orig/policy/lang.xml selinux-doc-1.12/policy/lang.xml
--- selinux-doc-1.12.orig/policy/lang.xml	2004-02-26 22:36:47.000000000 +0200
+++ selinux-doc-1.12/policy/lang.xml	2004-05-24 21:11:55.000000000 +0300
@@ -1,14 +1,14 @@
 <sect1 id="lang"><title>Policy Language and the Example Policy Configuration</title>
 <para>
 The policy configuration is specified using a simple declarative
-language, originally documented informally in <citation><XRef
-LinkEnd="LoscoccoNSATR01"></citation>.  An example security policy
+language, originally documented informally in <citation><xref
+linkend="LoscoccoNSATR01"/></citation>.  An example security policy
 configuration was written in this language to demonstrate how SELinux
 can be used to meet certain security goals and to provide a starting
 point for users.  The example policy configuration was originally
-documented in <citation><XRef LinkEnd="SmalleyNAITR01"></citation> and
-was also discussed in <citation><XRef
-LinkEnd="LoscoccoOLS01"></citation>.  This section describes the
+documented in <citation><xref linkend="SmalleyNAITR01"/></citation> and
+was also discussed in <citation><xref
+linkend="LoscoccoOLS01"/></citation>.  This section describes the
 policy language, using the example configuration when possible to
 illustrate the language constructs.  This section also describes the
 logically separate file contexts configuration.
@@ -33,7 +33,7 @@
 Flask definitions, TE and RBAC declarations and rules, user
 declarations, constraint definitions, and security context
 specifications.  The Flask definitions were discussed in <xref
-linkend="archdefs">.  The TE and RBAC declarations and rules specify
+linkend="archdefs"/>.  The TE and RBAC declarations and rules specify
 the policy logic for the TE and RBAC models.  The user declarations
 define the users for the user identity model and authorize each user
 for particular roles.  The constraint definitions specify additional
@@ -74,8 +74,8 @@
 type transition rule, a type change rule, an access vector rule, or an
 assertion.  A RBAC statement can be a role declaration, a role
 dominance definition, or a role allow rule.  The TE statements are
-described in <xref linkend="telang">, and the RBAC statements are
-described in <xref linkend="rbaclang">.
+described in <xref linkend="telang"/>, and the RBAC statements are
+described in <xref linkend="rbaclang"/>.
 </para>
 
 </sect2>
@@ -174,7 +174,7 @@
 
 <sect3 id="telabel"><title>TE Transition Rules</title>
 <para>
-As described in <xref linkend="temodel">, TE transition rules specify the
+As described in <xref linkend="temodel"/>, TE transition rules specify the
 new domain for a process or the new type for an object.  In either
 case, the new type is based on a pair of types and a class.  For a
 process, the first type, referred to as the source type, is the
@@ -236,7 +236,7 @@
 It is often desirable to specify a single TE transition rule that
 specifies the new type for a set of related classes, e.g. all file
 classes.  Hence, a set of macros are defined for related classes, as
-shown in <xref linkend="classmacros">.  Any one of these macros can be
+shown in <xref linkend="classmacros"/>.  Any one of these macros can be
 used in the class field of a TE transition rule, as shown in the
 following:
 <programlisting>
@@ -244,9 +244,9 @@
 type_transition cardmgr_t tmp_t:devfile_class_set cardmgr_dev_t;
 </programlisting>
 
-<table id="classmacros" frame=all>
+<table id="classmacros" frame="all">
 <title>Class Macros</title>
-<tgroup cols=2 align=left>
+<tgroup cols="2" align="left">
 <thead>
 <row>
     <entry>Macro Name</entry>
@@ -354,7 +354,7 @@
 <para>
 A TE access vector rule specifies a set of permissions based on a type
 pair and an object security class.  These rules define the TE access
-matrix, as discussed in <xref linkend="temodel">.  Rules can be
+matrix, as discussed in <xref linkend="temodel"/>.  Rules can be
 specified for each kind of access vector, including the allowed,
 auditallow, and auditdeny vectors.  The syntax of an access vector rule is:
 <programlisting>
@@ -412,17 +412,17 @@
 permissions.  As with the class macros, care should
 be taken when using these macros to avoid granting unintended
 accesses.  Some of these macros are shown in <xref
-linkend="filepermmacros">, <xref linkend="socketpermmacros">, and
-<xref linkend="ipcpermmacros">.  Any one of these macros can be used in the
+linkend="filepermmacros"/>, <xref linkend="socketpermmacros"/>, and
+<xref linkend="ipcpermmacros"/>.  Any one of these macros can be used in the
 permissions field of a TE transition rule, as shown in the following:
 <programlisting>
 allow sshd_t sshd_tmp_t:notdevfile_class_set create_file_perms;
 allow sshd_t sshd_tmp_t:dir create_dir_perms;
 </programlisting>
 
-<table id="filepermmacros" frame=all>
+<table id="filepermmacros" frame="all">
 <title>File Permission Macros</title>
-<tgroup cols=2 align=left>
+<tgroup cols="2" align="left">
 <thead>
 <row>
     <entry>Macro Name</entry>
@@ -486,9 +486,9 @@
 </tgroup>
 </table>
 
-<table id="socketpermmacros" frame=all>
+<table id="socketpermmacros" frame="all">
 <title>Socket Permission Macros</title>
-<tgroup cols=2 align=left>
+<tgroup cols="2" align="left">
 <thead>
 <row>
     <entry>Macro Name</entry>
@@ -516,9 +516,9 @@
 </tgroup>
 </table>
 
-<table id="ipcpermmacros" frame=all>
+<table id="ipcpermmacros" frame="all">
 <title>IPC Permission Macros</title>
-<tgroup cols=2 align=left>
+<tgroup cols="2" align="left">
 <thead>
 <row>
     <entry>Macro Name</entry>
@@ -556,7 +556,7 @@
 </para>
 
 <para>
-As discussed in <xref linkend="telabel">, macros are defined for
+As discussed in <xref linkend="telabel"/>, macros are defined for
 common groupings of TE transition rules and TE access vector rules,
 e.g. <constant>domain_auto_trans</constant> and
 <constant>file_type_auto_trans</constant>.  In some cases, it is
@@ -578,13 +578,13 @@
 
 <para>
 Other macros are also defined for common groupings of TE access vector
-rules.  Some of the macros are listed in <xref linkend="teavmacros">.
+rules.  Some of the macros are listed in <xref linkend="teavmacros"/>.
 As with other macros, care should be taken when using these macros to
 avoid granting unintended permissions.
 
-<table id="teavmacros" frame=all>
+<table id="teavmacros" frame="all">
 <title>TE Access Vector Rule Macros</title>
-<tgroup cols=3 align=left>
+<tgroup cols="3" align="left">
 <thead>
 <row>
     <entry>Macro Name</entry>
@@ -740,8 +740,8 @@
 currently used and this report does not discuss them in detail.  The
 syntax of a type member rule is identical to a TE transition rule except
 for the use of a <constant>type_member</constant> keyword.
-Polyinstantiation is discussed in <citation><XRef
-LinkEnd="SpencerUsenixSec99"></citation>.
+Polyinstantiation is discussed in <citation><xref
+linkend="SpencerUsenixSec99"/></citation>.
 </para>
 </sect3>
 
@@ -759,7 +759,7 @@
 
 <para>
 The TE configuration files are listed in <xref
-linkend="teconfigtable">.  The
+linkend="teconfigtable"/>.  The
 <filename>macros</filename> directory contains m4 macros that are
 used by the TE configuration.  The <filename>attrib.te</filename> file
 declares the type attributes.  The
@@ -772,9 +772,9 @@
 directory rather than in the <constant>types</constant> directory.
 The <filename>assert.te</filename> file specifies TE assertions.
 
-<table id="teconfigtable" frame=all>
+<table id="teconfigtable" frame="all">
 <title>TE Configuration Files</title>
-<tgroup cols=2 align=left>
+<tgroup cols="2" align="left">
 <thead>
 <row>
     <entry>Filename</entry>
@@ -924,7 +924,7 @@
 not control role transitions based on the type of the entrypoint
 program.  However, role transitions can be restricted based on type
 attributes using the constraints configuration, as discussed in <xref
-linkend="constraintlang">.  The syntax of a role allow rule is:
+linkend="constraintlang"/>.  The syntax of a role allow rule is:
 <programlisting>
 role_allow_rule -> ALLOW current_roles new_roles ';'
 current_roles -> set
@@ -1024,7 +1024,7 @@
 user identity using the <function>execve_secure</function> system
 call.  The ability to transition to a different user identity can be
 controlled based on the TE domain through the constraints
-configuration, as discussed in <xref linkend="constraintlang">.  There
+configuration, as discussed in <xref linkend="constraintlang"/>.  There
 are no user transition or user allow rules in the policy language.
 Examples of user declarations are shown below:
 <programlisting>
@@ -1057,7 +1057,7 @@
 The <constant>user_u</constant> user identity is a generic user
 identity for unprivileged users that do not need to be separated by
 the policy.  This concept was introduced in <xref
-linkend="identitymodel">.  There should be no corresponding Linux user
+linkend="identitymodel"/>.  There should be no corresponding Linux user
 identity in <filename>/etc/passwd</filename> for this user.  The
 modified daemons will map Linux users who do not have a particular
 entry defined in the <filename>users</filename> file to this generic
@@ -1113,7 +1113,7 @@
           R1 role_op R2 | R1 op role_set | R2 op role_set
           T1 op T2 | T1 op type_set | T2 op type_set
 not -> '!' | NOT
-and -> '&&' | AND
+and -> '&amp;&amp;' | AND
 or -> '||' | OR
 op -> '==' | '!=' 
 role_op -> op | DOM | DOMBY | INCOMP
@@ -1191,7 +1191,7 @@
 
 <sect3 id="initialsidcontexts"><title>Initial SID Contexts</title>
 <para>
-As discussed in <xref linkend="arch">, initial SIDs are SID values
+As discussed in <xref linkend="arch"/>, initial SIDs are SID values
 that are reserved for system initialization or predefined objects.
 The initial SID contexts configuration specifies a security context for
 each initial SID.  A security context consists of a user identity, a role,
@@ -1422,7 +1422,7 @@
 
 <sect2 id="fileconlang"><title>File Contexts Configuration</title>
 <para>
-As explained in <xref linkend="archconcepts">, the security contexts
+As explained in <xref linkend="archconcepts"/>, the security contexts
 of persistent files are maintained using a persistent label mapping in
 each filesystem. The persistent label mapping is initialized during
 installation using the <command>setfiles</command> program.  This
diff -Naur selinux-doc-1.12.orig/policy/main.xml selinux-doc-1.12/policy/main.xml
--- selinux-doc-1.12.orig/policy/main.xml	2004-02-26 23:34:40.000000000 +0200
+++ selinux-doc-1.12/policy/main.xml	2004-05-24 21:30:20.000000000 +0300
@@ -1,15 +1,16 @@
-<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[
-<!ENTITY intro SYSTEM "intro.sgml">
-<!ENTITY arch SYSTEM "arch.sgml">
-<!ENTITY model SYSTEM "model.sgml">
-<!ENTITY lang SYSTEM "lang.sgml">
-<!ENTITY build SYSTEM "build.sgml">
-<!ENTITY apps SYSTEM "apps.sgml">
-<!ENTITY examples SYSTEM "examples.sgml">
-<!ENTITY biblio SYSTEM "biblio.sgml">
+<?xml version='1.0'?>
+<!DOCTYPE article PUBLIC "-//Norman Walsh//DTD DocBk XML V4.2//EN" "/usr/share/sgml/docbook/dtd/xml/4.2/docbookx.dtd" [
+<!ENTITY intro SYSTEM "intro.xml">
+<!ENTITY arch SYSTEM "arch.xml">
+<!ENTITY model SYSTEM "model.xml">
+<!ENTITY lang SYSTEM "lang.xml">
+<!ENTITY build SYSTEM "build.xml">
+<!ENTITY apps SYSTEM "apps.xml">
+<!ENTITY examples SYSTEM "examples.xml">
+<!ENTITY biblio SYSTEM "biblio.xml">
 ]>
 <article class="whitepaper" id="SELinuxPolicy" lang="en">
- <artheader>
+ <articleinfo>
  <title>Configuring the SELinux Policy</title>
  <author>
  <firstname>Stephen</firstname> 
@@ -22,14 +23,14 @@
  <pubsnumber>NAI Labs Report #02-007</pubsnumber>
  <pubdate>Initial:  February 2002, Last revised:  January 2003</pubdate>
  <contractsponsor>This work supported by NSA contract MDA904-01-C-0926 (SELinux)</contractsponsor>
- </artheader>
+ </articleinfo>
 
-&intro
-&arch
-&model
-&lang
-&build
-&apps
-&examples
-&biblio
+&intro;
+&arch;
+&model;
+&lang;
+&build;
+&apps;
+&examples;
+&biblio;
 </article>

Reply to:

Follow-Ups:
- Re: SE Linux
  - From: Neil Roeth <neil@debian.org>

References:
- SE Linux
  - From: Russell Coker <russell@coker.com.au>

Prev by Date: ITH: libicu28 (overriding parts of icu)
Next by Date: Re: Resignation
Previous by thread: SE Linux
Next by thread: Re: SE Linux
Index(es):
- Date
- Thread