diff --git a/latex2html-2018.tar.gz b/latex2html-2018.tar.gz
deleted file mode 100644
index 7ad00f9..0000000
--- a/latex2html-2018.tar.gz
+++ /dev/null
@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:09e37526d169e77c266c23122348998a0841c3d50866e45ff2550128157ad4e2
-size 1092431
diff --git a/latex2html-README.SUSE b/latex2html-README.SUSE
deleted file mode 100644
index 5156c76..0000000
--- a/latex2html-README.SUSE
+++ /dev/null
@@ -1,6 +0,0 @@
-Incompatibilities
-=================
-
-latex2html isn't fully compatible with the 'url' package. latex2html
-will die on the string "$$" in \path; e.g., \path{foo.$$}. For more
-info refer to Suse Linux Bugilla #26127.
diff --git a/latex2html-perl526.patch b/latex2html-perl526.patch
deleted file mode 100644
index e25fbdc..0000000
--- a/latex2html-perl526.patch
+++ /dev/null
@@ -1,71 +0,0 @@
-Index: latex2html-2017.2/configure
-===================================================================
---- latex2html-2017.2.orig/configure
-+++ latex2html-2017.2/configure
-@@ -1225,7 +1225,7 @@ if test "$?" != "0"; then
- fi
-
- # this is used to get the values from the config file
--eval `perl -w -e 'use cfgcache; foreach(keys %cfg) { print qq($_='"'"'$cfg{$_}'"'"'\n);}'`
-+eval `perl -w -e 'use lib q[.]; use cfgcache; foreach(keys %cfg) { print qq($_='"'"'$cfg{$_}'"'"'\n);}'`
-
-
-
-Index: latex2html-2017.2/latex2html.pin
-===================================================================
---- latex2html-2017.2.orig/latex2html.pin
-+++ latex2html-2017.2/latex2html.pin
-@@ -123,7 +123,7 @@ if($ENV{'L2HCONFIG'}) {
- require $ENV{'L2HCONFIG'} ||
- die "Fatal (require $ENV{'L2HCONFIG'}): $!";
- } else {
-- eval 'use l2hconf';
-+ eval 'use lib "."; use l2hconf';
- if($@) {
- die "Fatal (use l2hconf): $@\n";
- }
-@@ -1922,7 +1922,7 @@ sub mark_string {
- }
- $_[0] = join('',$before,"\{",$after) if($change);
- # MRO: mark one opening brace
-- if($_[0] =~ s/^([^{]*){/push(@processedB,$1);join('',$O,++$id,$C)/eos) {
-+ if($_[0] =~ s/^([^{]*)\{/push(@processedB,$1);join('',$O,++$id,$C)/eos) {
- $before=''; $after=$';
- }
- if ($after =~ /\}/) {
-Index: latex2html-2017.2/config/build.pl
-===================================================================
---- latex2html-2017.2.orig/config/build.pl
-+++ latex2html-2017.2/config/build.pl
-@@ -145,6 +145,7 @@ my ($VERSION) = q$Revision: 1.6 $ =~ /:\
- # Read in the system's configuration
- use FindBin;
- use lib "$FindBin::Bin/..";
-+use lib "$FindBin::Bin";
- use cfgcache;
-
- my $dd = $cfg{'dd'};
-Index: latex2html-2017.2/config/config.pl
-===================================================================
---- latex2html-2017.2.orig/config/config.pl
-+++ latex2html-2017.2/config/config.pl
-@@ -435,6 +435,7 @@ use IO::File;
-
- use FindBin;
- use lib "$FindBin::Bin/..";
-+use lib "$FindBin::Bin";
- use L2hos;
-
- #use diagnostics;
-Index: latex2html-2017.2/config/install.pl
-===================================================================
---- latex2html-2017.2.orig/config/install.pl
-+++ latex2html-2017.2/config/install.pl
-@@ -183,6 +183,7 @@ my ($VERSION) = q$Revision: 1.12 $ =~ /:
-
- use FindBin;
- use lib "$FindBin::Bin/..";
-+use lib "$FindBin::Bin";
- use cfgcache;
- use L2hos;
-
diff --git a/latex2html.1 b/latex2html.1
deleted file mode 100644
index 46ab672..0000000
--- a/latex2html.1
+++ /dev/null
@@ -1,114 +0,0 @@
-.00; # finish .ig
-
-'di \" finish diversion--previous line must be blank
-.nr nl 0-1 \" fake up transition to first page again
-.nr % 0 \" start at page 1
-'; __END__ ##### From here on it's a standard manual page - VERSION #####
-.TH LaTeX2HTML 1
-.AT 3
-.SH NAME
-latex2html \- translate LaTeX files to HTML (HyperText Markup Language)
-.SH SYNOPSIS
-.B
-
-latex2html
- [-address author-address]
- [-antialias]
- [-antialias_text]
- [-ascii_mode]
- [-auto_navigation]
- [-auto_prefix]
- [-biblio URL]
- [-bottom_navigation]
- [-contents URL]
- [-contents_in_navigation]
- [-custom_titles]
- [-debug]
- [-dir output-directory]
- [-discard]
- [-down_title string]
- [-down_url URL]
- [-external_file filename]
- [-external_images]
- [-font_size size]
- [-h(elp)]
- [-html_version (2.0|3.0|3.2)[,(math|i18n|table)]*]
- [-images_only]
- [-index URL]
- [-index_in_navigation]
- [-info string]
- [-init_file file]
- [-iso_language type]
- [-ldump]
- [-link num]
- [-local_icons]
- [-long_titles num]
- [-next_page_in_navigation]
- [-no_antialias]
- [-no_antialias_text]
- [-no_auto_link]
- [-no_footnode]
- [-no_fork]
- [-no_images]
- [-no_math]
- [-no_navigation]
- [-no_reuse]
- [-no_subdir]
- [-no_tex_defs]
- [-no_white]
- [-nolatex]
- [-numbered_footnotes]
- [-prefix filename-prefix]
- [-prev_title string]
- [-prev_url URL]
- [-previous_page_in_navigation]
- [-ps_images]
- [-reuse reuse_option]
- [-scalable_fonts]
- [-short_extn]
- [-short_index]
- [-show_section_numbers]
- [-split + num]
- [-split num]
- [-t top-page-title]
- [-tmp path]
- [-toc_depth num]
- [-toc_stars]
- [-top_navigation]
- [-unsegment]
- [-up_title string]
- [-up_url URL]
- [-v]
- [-verbosity num]
- [-white]
- file(s)
-
-
-.SH DESCRIPTION
-.I LaTeX2HTML
-is a Perl program that translates LaTeX source files into HTML. For each source
-file given as an argument the translator will create a directory containing the
-corresponding HTML files.
-See the WWW online documentation or the /usr/share/doc/packages/latex2html/manual.ps.gz
-file for more detailed information and examples.
-
-.SH PROBLEMS
-For information on various problems and remedies see the WWW online documentation
-or the documents available in the distribution.
-A mailing list for technical discussion about latex2html, bugs and enhancements is available at
-latex2html@tug.org
-
-.SH SUSE installation
-
-In /usr/share/doc/packages/latex2html you may find more information about this package.
-
-.SH AUTHOR
-Nikos Drakos, Computer Based Learning Unit, University of Leeds
-. Several people have contributed suggestions,
-ideas, solutions, support and
-encouragement.
-
-The pstogif script uses the pstoppm.ps
-postscript program originally written by Phillip Conrad (Perfect Byte, Inc.)
-and modified by L. Peter Deutsch (Aladdin Enterprises).
-
diff --git a/latex2html.changes b/latex2html.changes
index 8e93b03..95faf9e 100644
--- a/latex2html.changes
+++ b/latex2html.changes
@@ -1,3 +1,49 @@
+-------------------------------------------------------------------
+Wed Sep 11 18:49:17 UTC 2019 - pgajdos@suse.com
+
+- version update to 2019.2
+ * format author block consistently
+ https://bugs.debian.org/223565
+ * simplify build of manual
+ https://bugs.debian.org/639708
+ * convert -- to – and --- to —
+ If you want "--", use "-{}-", even inside \texttt{}
+ Behavior of \textt{--} in latex depends on font encoding.
+ https://bugs.debian.org/75416
+ * fix unicode in -html_version 5.0,math
+ * fix -notop_navigation (had no effect)
+ * remove obsolete "table" option
+ https://bugs.debian.org/276037
+ * fix "make test"
+ * ppmtopng syntax works with all versions of ppmtopng
+ * respect ./configure --with-perl=/bin/perl
+ * fallback for unknown column types, such as those
+ introduced by \newcolumntype.
+ https://bugs.debian.org/899306
+ * fix \sffamily
+ https://bugs.debian.org/111441
+ * produce svg images using pdftocairo
+ * use latex preview package to produce cropped images.pdf
+ * pdflatex by default
+ * dvipng by default
+ * html 5
+ * unicode input and output by default
+ * Support for packages luainputenc and polyglossia
+ * Support for picture generation via pdflatex, lualatex
+ or dvilualatex (options -use_pdftex, -use_luatex,
+ *use_luadvi correspondingly)
+ * perl 5.26: unescaped brace
+ * polski.perl: no translation until \prefixing command
+- use native `make test`
+- use latex2html.1 from tarball
+- deleted patches
+ - latex2html-perl526.patch (upstreamed)
+- deleted sources
+ - latex2html-README.SUSE (not needed)
+ - local.pm (not needed)
+ - testfile.tex (not needed)
+- added required texlive-preview
+
-------------------------------------------------------------------
Mon Dec 31 07:58:03 UTC 2018 - Petr Gajdos
diff --git a/latex2html.spec b/latex2html.spec
index 2c40796..ecf558e 100644
--- a/latex2html.spec
+++ b/latex2html.spec
@@ -1,7 +1,7 @@
#
# spec file for package latex2html
#
-# Copyright (c) 2018 SUSE LINUX GmbH, Nuernberg, Germany.
+# Copyright (c) 2019 SUSE LINUX GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
@@ -18,24 +18,19 @@
%define share_dir %{_datadir}/latex2html
Name: latex2html
-Version: 2018
+Version: 2019.2
Release: 0
Summary: LaTeX to HTML Converter
License: GPL-2.0-or-later
Group: Productivity/Publishing/TeX/Utilities
Url: http://www.ctan.org/tex-archive/support/latex2html
-Source0: http://mirrors.ctan.org/support/latex2html/latex2html-%{version}.tar.gz
+Source0: https://github.com/latex2html/latex2html/archive/v%{version}.tar.gz
Source1: latex2html-manual.tar.bz2
-Source2: latex2html-README.SUSE
-Source3: testfile.tex
-Source4: local.pm
-Source5: latex2html.1
Patch0: latex2html-share-dir.diff
Patch1: latex2html-perl-bindir.diff
Patch2: latex2html-dest-dir.diff
Patch3: latex2html-binmode.diff
Patch4: latex2html-backref-workaround.diff
-Patch5: latex2html-perl526.patch
BuildRequires: fdupes
BuildRequires: ghostscript-fonts-std
BuildRequires: ghostscript-x11
@@ -43,6 +38,7 @@ BuildRequires: netpbm
BuildRequires: texlive-dvips
BuildRequires: texlive-kpathsea
BuildRequires: texlive-latex
+BuildRequires: texlive-preview
Requires: ghostscript_any
Requires: latex2html-pngicons
Requires: netpbm
@@ -80,9 +76,6 @@ This subpackage contains the documentation for the Latex2HTML converter.
%patch2
%patch3
%patch4
-%patch5 -p1
-cp %{SOURCE2} README.SUSE
-cp %{SOURCE4} .
%build
# Not autotools based configure
@@ -92,16 +85,16 @@ make %{?_smp_mflags}
%install
%make_install
mkdir -p %{buildroot}/%{_mandir}/man1
-install -m 644 %{SOURCE5} %{buildroot}/%{_mandir}/man1
+install -m 644 latex2html.1 %{buildroot}/%{_mandir}/man1
rm -r %{buildroot}%{share_dir}/{docs,example,dot.latex2html-init}
chmod 755 %{buildroot}%{_datadir}/%{name}/{cweb2html/makemake.pl,cweb2html/cweb2html,makemap,makeseg/makeseg}
%fdupes -s %{buildroot}
%check
-LATEX2HTMLDIR=%{buildroot}/%{share_dir} ./latex2html --test_mode %{SOURCE3}
+make %{?_smp_mflags} test
%files
-%doc README.SUSE Changes FAQ README.md TODO dot.latex2html-init
+%doc Changes FAQ README.md TODO dot.latex2html-init
%{_prefix}/lib/latex2html
%dir %{share_dir}
%{share_dir}/*.pm
diff --git a/local.pm b/local.pm
deleted file mode 100644
index 8ecfb98..0000000
--- a/local.pm
+++ /dev/null
@@ -1,30 +0,0 @@
-#################################################################
-# local.pm
-#
-# Local Configuration for LaTeX2HTML
-#
-# This file is created automatically. Do not edit!
-#
-#################################################################
-
-package main;
-
-### start pstoimg configuration ###
-$GS_LIB = ' . ; /usr/share/ghostscript/5.50 ; /usr/share/ghostscript/fonts'; # Inserted by configure-pstoimg
-$GS_DEVICE = 'ppmraw'; # Inserted by configure-pstoimg
-$GS = '/usr/bin/gs'; # Inserted by configure-pstoimg
-$PNMCAT = '/usr/X11R6/bin/pnmcat'; # Inserted by configure-pstoimg
-$PNMFILE = '/usr/X11R6/bin/pnmfile'; # Inserted by configure-pstoimg
-$PNMTOPNG = '/usr/X11R6/bin/pnmtopng'; # Inserted by configure-pstoimg
-$PBMMAKE = '/usr/X11R6/bin/pbmmake'; # Inserted by configure-pstoimg
-$GSLANDSCAPE = '/usr/share/ghostscript/5.50/landscap.ps'; # Inserted by configure-pstoimg
-$PPMQUANT = '/usr/X11R6/bin/ppmquant'; # Inserted by configure-pstoimg
-$PNMFLIP = '/usr/X11R6/bin/pnmflip'; # Inserted by configure-pstoimg
-$bg_color = '\#bfbfbf'; # Inserted by configure-pstoimg
-$white_color = '\#ffffff'; # Inserted by configure-pstoimg
-$PNMCROP = '/usr/X11R6/bin/pnmcrop'; # Inserted by configure-pstoimg
-
-### end pstoimg configuration ###
-
-1;
-
diff --git a/testfile.tex b/testfile.tex
deleted file mode 100644
index 26f2a56..0000000
--- a/testfile.tex
+++ /dev/null
@@ -1,1303 +0,0 @@
-\documentclass[a4paper]{article}
-%\usepackage{graphicx}
-%\usepackage{subfigure}
-\usepackage[utf8]{inputenc}
-\usepackage{url}
-%\usepackage{times}
-
-\usepackage[pdftex,
- pdfauthor={Andreas Gruenbacher and Seth Arnold},
- pdftitle={AppArmor Technical Documentation},%
-\ifx\fixedpdfdate\@empty\else
- pdfcreationdate={\fixedpdfdate},
- pdfmoddate={\fixedpdfdate},
-\fi
- pdfsubject={AppArmor},
- pdfkeywords={AppArmor}
-]{hyperref}
-
-\hyphenation{App-Armor}
-\hyphenation{name-space}
-
-\renewcommand{\H}{\hspace{0pt}}
-
-\title{AppArmor Technical Documentation}
-\author{Andreas Gruenbacher and Seth Arnold \\
-\url{{agruen,seth.arnold}@suse.de} \\
-SUSE Labs / Novell}
-% don't include the (build!) date
-\date{}
-
-\begin{document}
-
-\maketitle
-
-\tableofcontents
-
-\newpage
-
-%\begin{abstract}
-%\end{abstract}
-
-\section{Introduction}
-
-In this paper we describe AppArmor from a technical point of view,
-introduce its concepts, and explain the design decisions taken. This
-text is intended for people interested in understanding why AppArmor
-works the way it does. You may be looking for less detailed, low-level,
-or kernel centric documentation; in that case, please refer to the
-AppArmor documentation web site~\cite{apparmor}.
-
-Sections~\ref{sec:overview} and ~\ref{sec:model} discuss the AppArmor
-security model, while Section~\ref{sec:walk-through} shows how to use it
-from a low-level point of view. Please be aware that lots of details
-are discussed here which the higher-level tools hide from the average
-user.
-
-
-\section{Overview}
-\label{sec:overview}
-
-AppArmor protects systems from insecure or untrusted processes by
-running them in confinement, still allowing them to share files with
-other parts of the system, exercising privilege, and communicating with
-other processes, but with some restrictions. These restrictions are
-mandatory; they are not bound to identity, group membership, or object
-ownership. In particular, the restrictions also apply to processes
-running with superuser privileges. AppArmor achieves this by plugging
-into the Linux Security Module (LSM) framework. The protections
-provided are in addition to the kernel's regular access control
-mechanisms.
-
-The AppArmor kernel module and accompanying user-space tools are
-available under the GPL license. (The exception is the libapparmor
-library, available under the LGPL license, which allows change\_hat(2)
-to be used by non-GPL binaries.)
-
-At the moment, AppArmor knows about two types of resources: files, and
-POSIX.1e (draft) capabilities. By controlling access to these
-resources, AppArmor can effectively prevent confined processes from
-accessing files in unwanted ways, from executing binaries which they are
-not meant to execute, and from exercising privileges such as acting on
-behalf of another user (which are traditionally restricted to the
-superuser).
-
-One use case for this kind of protection is a network daemon: even if
-the daemon is broken into, the additional restrictions imposed by
-AppArmor will prevent the attacker from attaining additional privileges
-beyond what the daemon is normally allowed to do. Because AppArmor
-controls which files a process can access in which ways down to the
-individual file level, the potential damage is much limited.
-
-There is work going on for teaching AppArmor about additional resources
-like ulimits, and interprocess and network communication, but at this
-time, these resource types are not covered. This is less severe than it
-might initially seem: in order to attack another process from a
-broken-into process like a network daemon, that other process has to
-actively listen. The set of actively listening processes is relatively
-small, and this sort of interprocess communication is a natural security
-boundary, so listening processes should be validating all their input
-already. For protection against bugs in the input validation of those
-processes, they should also be confined by AppArmor though, thus further
-limiting the potential damage.
-
-AppArmor protection is selective: it only confines processes for which
-policies (referred to as profiles) have been defined. All other
-processes will continue to run unrestricted by AppArmor.
-
-To confine a process, all it takes is to write a profile for it, take an
-existing profile, or automatically generate a profile: for the latter,
-the process can be run in \textit{learning} or \textit{complain} mode in
-which AppArmor allows all accesses, and logs all accesses that are not
-allowed by the current profile already. This log can then be used to
-automatically generate a suitable new profile, or refine an existing
-one. The application does not need to be modified.
-
-An example profile together with a complete low-level walk-through of
-AppArmor can be found in Section~\ref{sec:walk-through}. The
-apparmor.d(5) manual page contains further details.
-
-AppArmor is not based on labeling or label-based access and transition
-rules, so it does not stick a label on each each file in the file system
-(or more generally, on each object). It identifies files by name rather
-than by label, so if a process is granted read access to /etc/shadow and
-the system administrator renames /etc/shadow to /etc/shadow.old and
-replaces it with a copy (that may have an additional user in it, for
-example), the process will have access to the new /etc/shadow, and not
-to /etc/shadow.old.
-
-
-\section{The AppArmor Security Model}
-\label{sec:model}
-
-When a file is accessed by name with open(2), mkdir(2), etc., the kernel
-looks up the location of the object associated with the specified
-pathname in the file system hierarchy. The lookup is relative to the
-root directory for pathnames starting with a slash, and to the current
-working directory otherwise. Different processes can have have different
-working directories as well as different root directories. See
-path\_resolution(2) for a detailed discussion of how pathname resolution
-works.
-
-Either way, the result of the lookup is a pair of (dentry, vfsmount)
-kernel-internal objects that uniquely identify the location of the file
-in the file system hierarchy. The dentry points to the object if the
-object already exists, and is a placeholder for the object to be created
-otherwise.
-
-AppArmor uses the (dentry, vfsmount) pair to compute the pathname of the
-file within a process's filesystem namespace. The resulting pathname
-contains no relative pathname components (``.'' or ``..''), or symlinks.
-
-AppArmor checks if the current profile contains rules that match this
-pathname, and if those rules allow the requested access. Accesses
-that are not explicitly allowed are denied.
-
-
-\subsection{Symbolic Links}
-
-When looking up the (dentry, vfsmount) pair of a file, the kernel
-resolves symlinks where appropriate (and fails the lookup where symlink
-resolution is inappropriate).
-
-The pathname that AppArmor computes from a (dentry, vfsmount) pair never
-contains symlinks. This also means that if symlinks are used instead of
-directories for paths like /tmp, profiles need to be adjusted
-accordingly. A future version of AppArmor may have built-in support
-for this kind of pathname rewriting.
-
-
-\subsection{Namespaces}
-
-Linux allows different processes to live in separate namespaces, each of
-which forms an independent file system hierarchy. A recent paper by Al
-Viro and Ram Pai~\cite{ols06-pai} discusses all the intricate things
-possible with namespaces in recent 2.6 kernels.
-
-From the point of view of a process, an absolute path is a path that
-goes all the way up to the root directory of that process. This is
-ambiguous if processes have different root directories. Therefore,
-instead of paths relative to process root directories, AppArmor uses
-paths relative to the namespace root.
-
-Pathnames are meaningful only within a namespace. Each namespace has a
-root where all the files, directories, and mount points are hanging off
-from.
-
-The privilege of creating new namespaces is bound to the
-CAP\_{\H}SYS\_{\H}ADMIN capability, which grants a multitude of other
-things that would allow a process to break out of AppArmor confinement,
-so confined processes are not supposed to have this privilege, and
-processes with this capability need to be considered trusted.
-
-In this setup, privileged processes can still create separate namespaces
-and start processes in those namespaces; processes confinement will be
-relative to whatever namespace a process ends up in. It is unclear
-at this point how AppArmor should support separate namespaces --- either
-by computing all pathnames relative to one particular namespace
-considered global (assuming that such a globally meaningful namespace
-will exist in all setups in which AppArmor is relevant), or by allowing
-different sets of profiles to be associated with different namespaces.
-
-
-\subsection{Disconnected Files and Pseudo File Systems}
-
-In some situations, a process can end up with a file descriptor or
-working directory that was looked up by name at some point, but is not
-connected to the process's namespace anymore (and hasn't been deleted,
-either). This can happen when file descriptors are passed between
-processes that do not share the same namespace, or when a file system
-has been lazily unmounted (see the MNT\_DETACH flag of umount2(2)). Such
-files may still be visible to other processes, and they may become
-reconnected. AppArmor cannot compute the pathnames of such files.
-Granting unrestricted access would be insecure, and so AppArmor denies
-access to disconnected files.
-
-As a special case, the kernel supports a number of file systems that
-users can have file descriptors open for, but that can never be mounted.
-Those files are by definition disconnected. Anonymous pipes, futexes,
-inotify, and epoll are all examples of that. Accesses to those files
-is always allowed.
-
-Future versions of AppArmor will have better control over disconnected
-files by controlling file descriptor passing between processes.
-
-
-\subsection{Mount}
-
-Mounting can change a process's namespace in almost arbitrary ways.
-This is a problem because AppArmor's file access control is pathname
-based, and granting a process the right to arbitrarily change its
-namespace would subvert this protection mechanism. AppArmor therefore
-denies confined processes access to the mount(2), umount(2), and
-umount2(2) system calls.
-
-Future versions of AppArmor may offer fine-grained control over mount,
-and may grant confined processes specific mount operations.
-
-
-\subsection{The Kernel NFS Daemon}
-
-The security model of the various versions of NFS is that files are
-looked up by name as usual, but after that lookup, each file is only
-identified by a file handle in successive acesses. The file handle at a
-minimum includes some sort of filesystem identifier and the file's inode
-number. In Linux, the file handles used by most filesystems also
-include the inode number of the parent directory; this may change in the
-future. File handles are persistent across server restarts.
-
-This means that when the NFS daemon is presented with a file handle,
-clients must get access without having specified a pathname. A pathname
-can be computed from a (parent, child) inode pair that identifies the
-file down to the directory level if the dentry is properly connected to
-the dcache, but multiple hardlinks to the same file within the same
-directory cannot be distinguished, and properly connecting dentries
-comes at a cost in the NFS daemon. Because of this overhead and the
-questionable benefit, most setups do not guarantee that dentries will be
-connected, and so pathnames cannot always be computed. (See the
-no\_subtree\_check option in exports(5).)
-
-In addition, the NFS daemon is implemented in the kernel rather than as
-a user space process. There is no memory separation or other protection
-between the daemon and the rest of the kernel. This means that at best,
-the NFS daemon could cooperate with an additional access control
-mechanism like AppArmor --- but there would be no enforcement.
-
-Because of all of this, it makes little sense to put the kernel NFS
-daemon under AppArmor control. Administrators are advised to not assign
-profiles to the kernel nfsd daemons.
-
-
-\subsection{Why are the computed pathnames meaningful?}
-
-Whenever a process performs a name-based file access, the pathname or
-pathname component always refers to a specific path to that file: the
-path is either relative to the chroot if an absolute path is used, or
-else relative to the current working directory. The chroot or current
-working directory always has a unique pathname up to the namespace root
-(even if the process itself has no direct access above the chroot).
-This means that each name-based file access maps to a unique, canonical,
-absolute pathname. There may be additional paths pointing to the same
-file, but a particular name-based access still always refers to only one
-of them. These are the pathnames that AppArmor uses for permission
-checks.
-
-If directories along the path get renamed after a process changes into
-them (either with chroot(2) or with chdir(2)), the resulting pathname
-will differ from the pathnames that the process used. Consider the
-following sequence of operations for example:
-
-\begin{tabbing}
-\begin{tabular}{ll}
-\textbf{Process 1} & \textbf{Process 2} \\
-chdir("/var/tmp/foo"); & \\
- & rename("/var/tmp/foo", "/var/tmp/bar"); \\
-creat("baz", 0666); & \\
-\end{tabular}
-\end{tabbing}
-
-The creat operation will check against the path
-/var/tmp/\textit{bar}/baz, even though Process~1 never used
-\textit{bar.} This is the expected behavior; we are interested in the
-names of the objects along the path at the time of the access, not in
-their previous names.
-
-As already mentioned, a path lookup results in a pair of (dentry,
-vfsmount) kernel-internal objects. The pathname that AppArmor checks
-against is computed from these two objects after these objects have been
-looked up. The lookup and the pathname computation are not atomic, which
-means that pathname components could even be renamed after the lookup
-but before the pathname has been computed.
-
-It matters that the AppArmor access check is performed between the lookup and
-the actual access, but atomicity between the lookup and that access
-check is not necessary: there is no difference between a rename before
-the lookup and a rename after the lookup from AppArmor's point of view;
-all we care about is the current pathname at some point between the
-lookup and the access.
-
-A special case occurs when the lookup succeeds, but the file is deleted
-before the AppArmor access check. In this case the access is denied and
-errno is set to ENOENT, the same behavior as if the lookup had failed.
-
-
-\subsection{Path Permission Checking}
-
-On UNIX systems, when files are looked up by name, the lookup starts
-either at the root or the current working directory of a process. From
-there, each directory reached is checked for search permission (x). The
-permissions on the directories leading to the current working directory
-are not checked. When a file is being created or deleted, the parent
-directory of that file is checked for write and search access (wx).
-When a file is being accessed, the permissions of that file are checked
-for r, w, or x access, or a combination thereof. Each check can result
-in a failure with errno set to EACCES (Permission denied).
-
-In contrast, AppArmor first computes the pathname to a file. If a file
-is being created, the name being looked up is the name of the new file
-and not the name of the parent directory.
-
-If the file being looked up is a directory, AppArmor appends a slash to
-the pathname so that directory pathnames always end in a slash;
-otherwise the pathname will not end in a slash.
-
-It then checks for file access rules in the process's profile that match
-that pathname, and decides based on that. With some exceptions for
-execute modes as described in Section~\ref{sec:merging}, the permissions
-granted are the union of permissions of all matching rules.
-
-
-\subsection{Profile Permissions}
-\label{sec:permissions}
-
-AppArmor differentiates between slightly more permissions than UNIX
-does, as shown in Table~\ref{tab:permissions}: file access rules in
-AppArmor support the read (r), write (w), execute (x), memory map as
-executable (m), and link (l) permissions. The execute permission
-requires a modifier that further specifies which kind of execution is
-being granted: inherit the current profile (ix), use the profile defined
-for that executable (px), or execute unconfined without a profile (ux).
-In addition, the px and ux permissions have Px and Ux forms that will
-trigger Secure Execution (see Section~\ref{sec:secure-exec} below).
-The different permissions are used as follows:
-
-\begin{table}[tb]
-\center
-\begin{tabular}{|l|l|}
-\hline
-r & Read. \\
-w & Write. \\
-ix & Execute and inherit the current profile. \\
-px & Execute under a specific profile. \\
-Px & Execute secure and under a specific profile. \\
-ux & Execute unconfined. \\
-Ux & Execute secure and unconfined. \\
-m & Memory map as executable. \\
-l & Link. \\
-\hline
-\end{tabular}
-\caption{File Access Permissions in Profiles}
-\label{tab:permissions}
-\end{table}
-
-\begin{description}
-
-\item[Read.]
-The profile read permission is required by all system calls that
-require the UNIX read permission. This includes open with
-O\_RDONLY, getdents (i.e., readdir), listxattr, getxattr, and
-mmap with PROT\_READ.
-
-\item[Write.]
-The profile write permission is required by all system calls
-that require the UNIX write permission, except for operations
-that create or remove files: while UNIX requires write access to
-the parent directory, AppArmor requires write access on the new
-file in this case (which does not exist at the time of the
-permission check for file creates). Operations that create
-files include open with O\_CREAT, creat, mkdir, symlink, and
-mknod. Operations that remove files include rename, unlink and
-rmdir.
-
-Operations that require write access in UNIX as well as AppArmor
-include open with O\_WRONLY (O\_RDWR requires read and write),
-setxattr, removexattr, and mmap with PROT\_WRITE.
-
-Other system calls such as chmod, chown, utime, and utimes are
-bound to file ownership or the respective capabilities in UNIX.
-AppArmor also requires profile write access for those operations.
-
-\item[Execute.]
-As mentioned above, AppArmor distinguishes a few different ways
-how files may be executed as described above.
-
-For directories, the UNIX execute permission maps to search
-access. AppArmor does not control directory search access.
-Traversing directories is always granted.
-
-\item[Memory map as executable.]
-The Linux kernel only requires read access to files in order
-to memory map them for execution with the PROT\_EXEC flag.
-AppArmor makes a distinction here, and requires the m profile
-permission in order for files to be mapped as executable. That way,
-it is more obvious in profiles what applications are allowed to do even
-if from a security point of view, the m permission provides a similar
-level of protection as the ix permission --- execute under the current
-profile.
-
-\item[Link.]
-Creating a hardlink requires the profile link permission (l) on the new
-path. In addition, the new path must have a subset of the r, w, x, and
-m permissions of the old path, and if the new path has the x permission,
-the execute flags (i, u, U, p, and P) of the old and the new path must
-be equal.
-
-\item[Rename.]
-A rename requires profile read and write access for the source
-file, and profile write access for the target file.
-
-\item[Stat.]
-Retrieving information about files is always allowed. We believe
-that providing policy for file information retrieval is more
-troublesome than the benefit it would provide.
-
-\end{description}
-
-
-\subsection{System Calls Taking File Handles, At System Calls}
-
-A number of system calls take file descriptors instead of pathnames as
-their parameters (ftruncate, fchmod, etc.), or take directory file
-descriptors, and resolve pathnames relative to those directories
-(openat, mkdirat, etc.). These system calls are treated like their
-non-f and non-at equivalents, and the same access checks are performed.
-At the point where AppArmor is asked to validate those file accesses, it
-is passed a (dentry, vfsmount) pair no matter which system call variant
-is used.
-
-
-\subsection{File Descriptor Passing and Revalidation}
-
-After a file descriptor has been obtained, the permitted accesses (read
-and/or write) are encoded in the file descriptor, and reads and writes
-are not revalidated against the profile for each access. This is
-consistent with how access checks are done in UNIX; such access checks
-would have a severe performance impact.
-
-The picture changes when a file descriptor is passed between processes
-and the other process is running under a different profile, or when a
-process switches profiles: in that case, read and write accesses are
-revalidated under the new profile. If the new profile does not allow
-them, the access is denied and errno is set to EACCES (Permission
-denied).
-
-File descriptors opened by unconfined processes are exempt from this
-rule. This is so that processes will still have access to their stdin,
-stdout, and stderr without having to list all possible sources of input
-and output in all profiles.
-
-
-\subsection{Deleted Files}
-
-Revalidation is problematic for deleted files for which a process still
-has an open file descriptor --- after all, the idea of the pathname of a
-deleted file is somewhat peculiar: the file is no longer reachable by
-any pathname, and it also cannot become re-attached to the filesystem
-namespace again.
-
-The traditional UNIX behavior is to determine access upon file access,
-and to never check again. Applications depend on this, particularly for
-temporary files. In addition to temporary files, deleted files can be
-used as an interprocess communication mechanism if the file descriptor
-is shared among multiple processes.
-
-AppArmor grants access to deleted files, just like it grants access to
-files opened by unconfined processes. It may control interprocess
-communication, including file descriptor passing, in a future version.
-
-
-\subsection{The access System Call}
-
-This system call determines whether a process has a given mode of access
-to a file in terms of the read, write, and execute permissions. This is
-not a sufficient replacement for performing the access check at the time
-of access even under traditional UNIX, because the access system call
-and the subsequent access are not atomic, and the permissions might
-change between the two operations. Applications are not supposed to rely
-on access(2).
-
-AppArmor introduces additional restrictions, some of which cannot be
-modeled in terms of read, write, and execute: for example, an AppArmor
-profile may allow a process to create files /tmp/foo-*, but not any
-other files in /tmp.
-
-There is no way to express this with access(2); in traditional UNIX, all
-that is required for creating files is write access to the parent
-directory. Access(2) will indicate that some accesses are allowed even
-when AppArmor will eventually deny them.
-
-
-\subsection{The ptrace System Call}
-
-The ability to ptrace allows a process to look up information about
-another process, read and write the memory of that process, and attach
-to (or trace) that process in order to debug it, or analyze its
-behavior. This gives total control over the process being traced, and
-so the kernel employs some restrictions over which processes may ptrace
-with other processes.
-
-In addition to these restrictions, AppArmor requires that if the tracing
-task is confined, it must either have the CAP\_{\H}SYS\_{\H}PTRACE capability,
-or be confined by the same profile and sub-profile as the process being
-traced. Attempts to switch to another profile or sub-profile by a
-process being traced is denied.
-
-
-\subsection{Secure Execution}
-\label{sec:secure-exec}
-
-In this mode, the kernel passes a flag to user space. When glibc finds
-this flag set, it unsets environment variables that are considered
-dangerous, and it prevents the dynamic loader from loading libraries
-controlled by the environment. With non-secure exec, the
-LD\_LIBRARY\_PATH environment variable can be used to switch to a
-different set of libraries, for example. The secure exec mechanism is
-not specific to AppArmor: set-user-id and set-group-id executables also
-use it, as well as SELinux, which introduced this glibc feature.
-
-
-\subsection{Exec Mode Merging in Profiles, Exact Matches}
-\label{sec:merging}
-
-When more than one rule in a profile matches a given path, all the
-permissions accumulate except for ix, px, Px, ux, and Ux: those
-permissions would conflict with each other; it would be unclear how to
-execute the new binary if more than one of these flags was set. To deal
-with this situation, AppArmor differentiates between rules that define
-exact matches and wildcard rules (see Table~\ref{tab:globbing} on
-page~\pageref{tab:globbing}). Execute flags in exact matches override
-execute flags in wildcard matches.
-
-If the execute flags of multiple rules still disagree, the profile is
-rejected at profile load time.
-
-
-\subsection{Capabilities}
-
-AppArmor uses the standard Linux capability mechanism. When the kernel
-checks if a certain capability can be exercised, AppArmor additionally
-checks if the current profile allows the requested capability, and
-rejects the use of the capability otherwise.
-
-
-\subsection{The sysctl System Call and /proc/sys}
-
-The sysctl system call and files below /proc/sys
-can be used to read and modify various kernel parameters. Root processes
-can easily bring the system down by setting kernel parameters to invalid
-values. To prevent against that, AppArmor denies confined processes
-that do not have the CAP\_{\H}SYS\_{\H}ADMIN capability write access to kernel
-parameters.
-
-
-\subsection{Subprofiles aka. Hats}
-
-Profiles can contain subprofiles that processes may switch to from the
-main profile. Switching from a subprofile into a sibling subprofile or
-back to the parent profile is allowed depending on how the subprofile
-was entered, and provided that the child knows a magic cookie.\footnote{
- \textbf{A word of warning about change\_hat(2):} When used with a
- non-zero magic cookie for changing into a subprofile, that magic
- cookie can be used to change back out of the subprofile; in this
- mode, change\_hat(2) is not a strong confinement mechanism. If the
- code running in the subprofile can guess the magic cookie, it can
- break out of the subprofile. Likewise, if that code can manipulate
- the processes' behavior beyond the point where the process returns
- from the subprofile, it can influence what is done under the parent
- profile. Therefore, change\_hat(2) with a non-zero magic cookie is
- only safe in combination with restricted code environments, such as
- when the subprofile is used for executing Safe Perl (see Safe(3pm)),
- etc.
-} See the change\_hat(2) manual page for details.
-
-Each process may consist of multiple tasks. Each task may only change
-its own subprofile. The superuser cannot put a task into a different
-hat, but he can replace the entire profile and its subprofiles, or he
-can put a process in a different top-level profile (see
-Section~\ref{sec:association}).
-
-Internally, change\_hat(2) is implemented by writing to a special
-kernel-provided file. This is equivalent to a command like:
-
-\begin{small}
-\begin{verbatim}
- $ echo "changehat 123^hat_name" > /proc/$PID/attr/current
-\end{verbatim}
-\end{small}
-
-Here, the number is the magic cookie value, and hat\_name obviously is
-the name of the hat; either may be replaced by the empty string (but not
-both).
-
-
-\subsection{Association of Profiles with Processes}
-\label{sec:association}
-
-Profiles are associated with kernel tasks, which roughly correspond to
-threads in user space (see clone(2) for details). Currently there are
-two ways how a profile can be associated with a task: when an executable
-is started and a profile is defined for that executable, or when the
-administrator assigns a profile to a task explicitly.
-
-In addition to that, once a task is confined by a profile, that profile
-determines which other executables may be executed, and under which
-profile they may run (under the profile defined for that executable, the
-same profile as the current task, or unconfined; see
-Section~\ref{sec:permissions}).
-
-A process will consist of a single task after an exec, so in the exec
-case, the entire process will be confined. New tasks (threads as well
-as processes) inherit the same profile and subprofile as their parent
-task.
-
-Unconfined processes with the CAP\_{\H}SYS\_{\H}ADMIN privilege may assign a
-profile to a task with a command like this:
-
-\begin{small}
-\begin{verbatim}
- $ echo "setprofile /name/of/profile" > \
- /proc/$PID/attr/current
-\end{verbatim}
-\end{small}
-
-After that, the task will be in the new top-level profile, even if the
-process was in a subprofile before.
-
-Processes with the CAP\_{\H}SYS\_{\H}ADMIN privilege as well as the process itself
-can query the profile a process is in by reading from that file:
-
-\begin{small}
-\begin{verbatim}
- $ cat /proc/$PID/attr/current
- unconfined
-
- $ cat /proc/$PID/attr/current
- /name/of/profile (complain)
-
- $ cat /proc/$PID/attr/current
- /name/of/profile^hat_name (enforce)
-\end{verbatim}
-\end{small}
-
-The output includes the name of the profile and subprofile as well as
-the mode the active profile is in. (When a task is in a subprofile,
-the subprofile is the active profile.)
-
-\subsection{Profile Loading, Replacement, and Removal}
-
-Before the kernel can use any profiles, they must be loaded. The
-profile sources consist of plain text. This text representation is
-converted into in a binary representation that the kernel can more
-easily deal with by the user-space profile loader.
-
-Profiles contain potentially long lists of file access rules that may
-include wildcards. In order to make the lookup efficient, the AppArmor
-kernel module does not actually go through all the file access rules
-when checking for access. Instead, the profile loader takes those rules
-and compiles them into transition tables. Pathnames are then looked up
-in those tables with a simple and efficient algorithm, the theory behind
-which is explained in the Lexical Analysis section of the Dragon
-Book~\cite{dragon86}.
-
-An init script loads all the known profiles into the kernel at an early
-boot stage. This happens automatically and the system administrator
-tools will take care of loading, reloading, or removing profiles after
-they manipulate them, so end users will not usually notice this step.
-
-Profiles can be replaced at any time during runtime, and all processes
-running under old profiles will transparently be switched to the updated
-versions. Profiles can also be removed. All processes running under a
-profile that is removed will become unconfined.
-
-Profiles are always replaced together with all their subprofiles. It
-may be that an updated profile no longer contains a specific subprofile.
-If that happens while processes are using that subprofile, those
-processes will be put in a profile that denies all accesses. Such
-processes may still change to sibling subprofiles or back to the parent
-profile subject to the change\_hat(2) semantics.
-
-
-\section{AppArmor Walk-Through}
-\label{sec:walk-through}
-
-AppArmor consists of a set of kernel patches and accompanying
-user-space tools, both of which are available at
-\url{http://developer.novell.com/wiki/index.php/Apparmor}.
-
-
-\subsection{Kernel Patches and Configuration}
-
-The AppArmor kernel patches are provided in a format convenient for use
-with quilt,\footnote{
- \url{http://savannah.nongnu.org/projects/quilt}
-} however, other tools for applying the patches can be used, too. The
-patches are supposed to apply against recent kernel.org git kernels. A
-copy of the current git tree can be obtained from
-\url{git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git}
-with \textit{git clone} (see the \hbox{git-clone(1)} manual page). In
-case the the differences between the latest git tree and the tree the
-AppArmor patches are based on is too big, the patches won't apply
-cleanly. In this case, trying an older git tree may work better.
-
-After obtaining the AppArmor patches tarball and the git tree which will
-end up in the linux-2.6 directory by default, the AppArmor patches can
-be applied to the git tree as follows:
-
-\begin{small}
-\begin{verbatim}
- $ tar zxvf apparmor.tar.gz
- $ cd linux-2.6/
- $ ln -s ../apparmor patches
- $ quilt push -a
-\end{verbatim}
-\end{small}
-
-When configuring the kernel, make sure that AppArmor is built in or as a
-module (CONFIG\_{\H}SECURITY\_{\H}APPARMOR must be 'y' or 'm'). AppArmor
-cannot be used together with other Linux Security Modules, so if
-CONFIG\_{\H}SECURITY\_{\H}CAPABILITIES or CONFIG\_{\H}SECURITY\_{\H}SELINUX is
-set to 'y', they must be disabled by adding \texttt{selinux=0} and/or
-\texttt{capability.disable=1} to the kernel command line (grub, lilo,
-yaboot, etc.). It is not sufficient to put SELinux into permissive
-mode --- at this time, AppArmor cannot be combined with other LSMs.
-
-\subsection{The securityfs file system}
-
-AppArmor uses securityfs for configuration and to report information.
-The usual mountpoint for securityfs is /sys/{\H}kernel/{\H}security.
-Unless your distribution automatically does so, you can mount securityfs
-with:
-
-\begin{small}
-\begin{verbatim}
- $ mount securityfs -t securityfs /sys/kernel/security
-\end{verbatim}
-\end{small}
-
-Once securityfs has been mounted and the apparmor module loaded,
-/sys/{\H}kernel/{\H}security/{\H}apparmor/{\H}profiles will show the
-profiles loaded into the kernel, as well as mark if the profiles are in
-enforcement mode or in learning mode:
-
-\begin{small}
-\begin{verbatim}
- $ cat /sys/kernel/security/apparmor/profiles
- /usr/bin/opera (complain)
- /usr/lib/firefox/firefox.sh (complain)
- /sbin/lspci (enforce)
- ...
-\end{verbatim}
-\end{small}
-
-Profile loading, replacement, and unloading, as well as configuration of
-AppArmor is also done via securityfs.
-
-%/sys/kernel/security/apparmor/control/ control seldom-used features of AppArmor:
-% audit if '1', audit all actions by confined processes
-% complain if '1', allow all actions by confined processes, report
-% accesses not granted by policy
-% debug if '1', emit copius debugging
-% logsyscall if '1', use audit framework's syscall debugging, if audit
-% has been instructed to create per-task contexts.[2]
-
-\subsection{Profile Loading}
-
-Profile loading, replacement, and removal is performed by the
-apparmor\_parser utility from the apparmor-parser package. The
-package can easily be built by running make in the package's top-level
-directory. Once that is done and the AppArmor module loaded, you may
-use the parser to load profiles with:
-
-\begin{small}
-\begin{verbatim}
- $ echo "/tmp/ls { /tmp/ls rm, }" | apparmor_parser
-\end{verbatim}
-\end{small}
-
-Once a profile for a program has been loaded into the kernel, you must
-use the --replace option for replacing the existing profile with a new
-one (this option may be used even if no profile by that name exists):
-
-\begin{small}
-\begin{verbatim}
- $ echo "/tmp/ls { /tmp/ls rm, }" | apparmor_parser --replace
-\end{verbatim}
-\end{small}
-
-\subsection{Anatomy of a Profile}
-
-AppArmor profiles use a simple declaritive language, fully described in
-the apparmor.d(5) manual page. By convention, profiles are stored in
-/etc/{\H}apparmor.d/. The AppArmor parser supports a simple cpp-style
-include mechanism to allow sharing pieces of policy. A simple profile
-looks like this:
-
-\begin{small}
-\begin{verbatim}
- /bin/ls flags=(complain) {
- /bin/ls rm,
- /lib/ld-2.5.so rmix,
- /etc/ld.so.cache rm,
- /lib/lib*.so* rm,
-
- /dev/pts/* w,
-
- /proc/meminfo r,
- /var/run/nscd/socket w,
- /var/run/nscd/passwd r,
- /var/run/nscd/group r,
-
- /tmp/ r,
- }
-\end{verbatim}
-\end{small}
-
-Here, the first /bin/ls is the name of the profile. This profile will be
-automatically used whenever an unconfined process executes /bin/ls. The
-flags instruct AppArmor to put the profile in complain (aka. learning)
-mode: in this mode, all operations are allowed, and any events that
-would have been denied are logged. This helps users to incrementally
-deploy AppArmor in production environments. The default if no flags are
-specified is enforcement mode, in which all operations not allowed by
-the profile are logged and denied.
-
-Complain mode can be enabled individually for profiles as shown above
-(followed by reloading the profile), or by globally putting all profiles
-in complain mode with:
-
-\begin{small}
-\begin{verbatim}
- $ echo 1 > /sys/kernel/security/apparmor/control/complain
-\end{verbatim}
-\end{small}
-
-The user-space tools also include two small utilities, enforce and
-complain, which will put profiles into enforce or complain mode:
-
-\begin{small}
-\begin{verbatim}
- $ enforce firefox
- Setting /usr/lib/firefox/firefox.sh to enforce mode.
-\end{verbatim}
-\end{small}
-
-Inside the body of the profile are any number of rules consisting of a
-pathname expression that may include globbing, and a set of permissions.
-Table~\ref{tab:globbing} shows the supported shell-inspired globbing
-constructs; Section~\ref{sec:permissions} on
-page~\pageref{sec:permissions} describes the permissions.
-
-\begin{table}[tb]
-\center
-\begin{tabular}{|l|l|}
-\hline
-{?} & Any single character except ``/''. \\
-{*} & Any number of characters except ``/''. \\
-{**} & Any number of characters including ``/''. \\
-{[ab]} & One of ``a'' or ``b''. \\
-{[a-c]} & One of ``a'', ``b'', or ``c''. \\
-\{ab,cd\} & Alternation: either ``ab'' or ``cd''. \\
-\hline
-\end{tabular}
-\caption{Globbing in File Access Rules. Alternation counts as an exact
-match in file access rules; all others count as wildcards (see
-Section~\ref{sec:merging}).}
-\label{tab:globbing}
-\end{table}
-
-When AppArmor looks up a directory the pathname being looked up will end
-with a slash (e.g., /var/tmp/), otherwise it will not. Only rules
-that match that trailing slash will match directories. Some examples,
-none matching the /tmp directory itself, are:
-
-\begin{tabbing}
-\begin{tabular}{ll}
-{/tmp/*} & Files directly in /tmp. \\
-{/tmp/*/} & Directories directly in /tmp. \\
-{/tmp/**} & Files and directories anywhere underneath /tmp. \\
-{/tmp/**/} & Directories anywhere underneath /tmp. \\
-\end{tabular}
-\end{tabbing}
-
-As explained in Section~\ref{sec:model}, AppArmor does not require
-execute access to allow directory traversal, or write access on a
-directory to create or rename files inside the directory. Instead, write
-access is required on the specific files that a confined process
-attempts to create, remove, rename, etc. Read access is required for
-reading the contents of a directory.
-
-AppArmor also mediates the use of POSIX 1003.1e draft capabilities;
-capabilities that a process is allowed to use are listed in the
-profile by their name in lower-case (with ``CAP\_'' stripped off), e.g.,
-
-\begin{small}
-\begin{verbatim}
- #include
-
- /sbin/lspci {
- #include
- #include
-
- capability sys_admin,
-
- /sbin/lspci mr,
- /sys/bus/pci/ r,
- /sys/bus/pci/devices/ r,
- /sys/devices/** r,
- /usr/share/pci.ids r,
- }
-\end{verbatim}
-\end{small}
-
-This profile uses predefined include files which are part of the
-apparmor-profiles package.
-
-\subsection{Logging}
-
-AppArmor uses the kernel standard audit facility for reporting. When a
-profile is in complain mode, the log messages look like this:
-
-\begin{small}
-\begin{verbatim}
- type=APPARMOR msg=audit(1174506429.573:1789): PERMITTING r access
- to /home/sarnold/ (ls(16504) profile /tmp/ls active /tmp/ls)
-\end{verbatim}
-\end{small}
-
-When a profile is in enforcement mode, the log messages look like this:
-
-\begin{small}
-\begin{verbatim}
- type=APPARMOR msg=audit(1174508205.298:1791): REJECTING r access
- to /bin/ (ls(16552) profile /tmp/ls active /tmp/ls)
-\end{verbatim}
-\end{small}
-
-These log messages are sent to the kernel auditing facility; if auditd
-is not running, the kernel will forward these messages to printk for
-collection by klogd. Auditd must be configured with --with-apparmor to
-enable the \#defines to handle AppArmor's message type correctly.
-
-AppArmor also logs some important events in the process lifecycle,
-such as when processes in learning mode fork and change domain via
-exec. These other events, while not strictly related to permissions
-requested by the process, help the genprof profile generation tool
-reconstruct when specific accesses are required by processes --- this
-allows the tool to make more relevant and meaningful policy suggestions.
-
-\subsection{Generating Profiles By Hand}
-
-While the majority of our users are expected to generate profiles with
-the help of our profile tools, it is possible to write policy by hand.
-This final section gives a very quick walkthrough generating a simple
-profile for firefox.
-
-Since the kernel resolves symlinks to their ``final destinations'' before
-presenting AppArmor with policy questions, we first must see if
-/usr/{\H}bin/{\H}firefox is a symlink or the shell script that starts firefox;
-on our system, it is a symlink:
-
-\begin{small}
-\begin{verbatim}
- $ ls -l /usr/bin/firefox
- lrwxrwxrwx 1 root root 25 Mar 21 13:36 /usr/bin/firefox ->
- ../lib/firefox/firefox.sh
-\end{verbatim}
-\end{small}
-
-So we will start a profile for /usr/{\H}lib/{\H}firefox/{\H}firefox.sh. This shell
-script will execute firefox-bin, as we will see later; when it does so,
-we will tell AppArmor to inherit this profile. Thus, firefox-bin will
-be executing under the profile for /usr/{\H}lib/{\H}firefox/{\H}firefox.sh.
-
-To get started, we can make some assumptions about the privileges that
-firefox will need (both as a shell script and as a fairly complex GUI
-application):
-
-\begin{small}
-\begin{verbatim}
- $ cat /etc/apparmor.d/usr.lib.firefox.firefox.sh
- /usr/lib/firefox/firefox.sh flags=(complain) {
- /usr/lib/firefox/firefox.sh r,
- /bin/bash rmix,
- /lib/ld-2.5.so rmix,
- /etc/ld.so.cache rm,
- /lib/lib*.so* rm,
- /usr/lib/lib*.so* rm,
- }
- $ apparmor_parser --reload < \
- /etc/apparmor.d/usr.lib.firefox.firefox.sh
- Replacement succeeded for "/usr/lib/firefox/firefox.sh".
-\end{verbatim}
-\end{small}
-
-The easiest way to see what accesses AppArmor allows, start a tail -F
-/var/{\H}log/{\H}audit/{\H}audit.log (or /var/{\H}log/{\H}messages, or wherever your audit
-messages are being sent). In another terminal, start firefox. tail will
-show a few hundred PERMITTING audit events like these:
-
-\begin{small}
-\begin{verbatim}
- type=APPARMOR msg=audit(1174512269.026:1804): PERMITTING rw access
- to /dev/tty (firefox(16950) profile /usr/lib/firefox/firefox.sh
- active /usr/lib/firefox/firefox.sh)
-
- type=APPARMOR msg=audit(1174512269.026:1805): PERMITTING r access
- to /usr/share/locale/locale.alias (firefox(16950) profile
- /usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)
-
- type=APPARMOR msg=audit(1174512269.026:1806): PERMITTING r access
- to /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION (firefox(16950)
- profile /usr/lib/firefox/firefox.sh active
- /usr/lib/firefox/firefox.sh)
-\end{verbatim}
-\end{small}
-
-Because we want this profile to be fairly simple we'll be fairly
-permissive, add a few more rules to the profile and reload:
-
-\begin{small}
-\begin{verbatim}
- /dev/tty rw,
- /usr/share/locale/** r,
- /usr/lib/locale/** r,
-\end{verbatim}
-\end{small}
-
-Now re-run firefox. There is no need to handle all log entries at once.
-In complain mode, AppArmor will only report accesses that are not in the
-profile. This makes it fairly easy to add a few rules and re-run the
-application to determine what privileges are still necessary. We get a
-few more messages:
-
-\begin{small}
-\begin{verbatim}
- type=APPARMOR msg=audit(1174512791.236:5356): PERMITTING r access
- to /usr/lib/gconv/gconv-modules.cache (firefox(17031) profile
- /usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)
-
- type=APPARMOR msg=audit(1174512791.236:5357): PERMITTING r access
- to /proc/meminfo (firefox(17031) profile
- /usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)
-
- type=APPARMOR msg=audit(1174512791.240:5358): PERMITTING x access
- to /bin/basename (firefox(17032) profile
- /usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)
-
- type=APPARMOR msg=audit(1174512791.240:5359): LOGPROF-HINT
- changing_profile pid=17032
-
- type=APPARMOR msg=audit(1174512791.240:5360): PERMITTING r access
- to /bin/basename (firefox(17032) profile
- null-complain-profile active null-complain-profile)
-
- ...
-
- type=APPARMOR msg=audit(1174512791.240:5364): PERMITTING mr access
- to /bin/basename (basename(17032) profile
- null-complain-profile active null-complain-profile)
-\end{verbatim}
-\end{small}
-
-
-So now, we add a few more rules:
-
-\begin{small}
-\begin{verbatim}
- /usr/lib/gconv/** r,
- /proc/meminfo r,
- /bin/basename rmix,
-\end{verbatim}
-\end{small}
-
-We selected ``rmix'' for /bin/basename --- most small shell utilities
-should not have a profile for themselves. There's nothing wrong with
-giving basename a profile, but the value of such a profile would be very
-limited. Giving other shell utilities their own profiles would be worse:
-the profile would need read access to the whole filesystem for shell
-scripts to function reliably. In our case, basename simply inherits
-privileges from another profile, then it has no more and no fewer
-privileges than the calling program --- which is often a fine tradeoff.
-
-The loader will need r and m access to execute basename, and we use ix
-to execute basename in the same profile. The kernel logs only reported
-r, m and x access; we have to choose the execute mode ourselves. Again,
-the standard user tools would prompt users for this decision and give
-consequences of decisions.
-
-We continue in this fashion, iteratively adding and changing rules as
-needed by the logs. Some of the logs report attribute modifications,
-such as:
-
-\begin{small}
-\begin{verbatim}
- type=APPARMOR msg=audit(1174519157.851:10357): PERMITTING
- attribute (mode,ctime,) change to
- /home/sarnold/.gnome2_private/ (firefox-bin(17338) profile
- /usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)
-\end{verbatim}
-\end{small}
-
-These need to be represented in the profile with simple w access.
-
-\begin{small}
-\begin{verbatim}
- /home/*/.gnome2_private/ w,
-\end{verbatim}
-\end{small}
-
-After nine iterations, the profile looks like this --- we have inserted
-blank lines between each iteration:
-
-\begin{small}
-\begin{verbatim}
- /usr/lib/firefox/firefox.sh flags=(complain) {
- /usr/lib/firefox/firefox.sh r,
- /bin/bash rmix,
- /lib/ld-2.5.so rmix,
- /etc/ld.so.cache rm,
- /lib/lib*.so* rm,
- /usr/lib/lib*.so* rm,
-
- /dev/tty rw,
- /usr/share/locale/** r,
- /usr/lib/locale/** r,
-
- /usr/lib/gconv/** r,
- /proc/meminfo r,
- /bin/basename rmix,
-
- /usr/bin/file rmix,
- /etc/magic r,
- /usr/share/misc/magic.mgc r,
- /bin/gawk rmix,
- /usr/lib/firefox/firefox-bin rmix,
-
- /usr/lib/firefox/lib*so rm,
- /opt/gnome/lib/lib*so* rm,
- /usr/share/X11/locale/* r,
- /var/run/nscd/socket w,
- /var/run/nscd/passwd r,
-
- /usr/share/X11/locale/** r,
- /home/*/.Xauthority r,
- /usr/lib/gconv/*so m,
- /home/*/.mozilla/** rw,
- /etc/resolv.conf r,
- /usr/lib/firefox/**.so rm,
- /usr/lib/firefox/** r,
-
- /etc/opt/gnome/** r,
- /var/run/dbus/system_bus_socket w,
- /etc/localtime r,
- /opt/gnome/lib/**.so rm,
- /var/cache/libx11/compose/* r,
- /tmp/orbit-*/ w,
- /dev/urandom r,
- /tmp/ r,
- /dev/null rw,
- /opt/gnome/lib/GConf/2/gconfd-2 rmix,
-
- /dev/log w,
- /tmp/orbit-*/* w,
- /tmp/gconfd-*/ r,
- /tmp/gconfd-*/** rwl,
- /home/*/.gconf/ r,
- /home/*/.gconf/* rw,
- /etc/fonts/** r,
- /var/cache/fontconfig/* r,
- /home/*/.fontconfig/** r,
- /usr/share/ghostscript/fonts/** r,
- /etc/passwd r,
- /var/tmp/ r,
- /bin/netstat rmix,
-
- /home/*/.gnome2_private/ w,
- /home/*/.gconfd/* rw,
- /proc/net/ r,
- /proc/net/* r,
- /usr/share/fonts/** r,
- /usr/lib/browser-plugins/ r,
- /usr/lib/browser-plugins/** rm,
- }
-\end{verbatim}
-\end{small}
-
-Sorting the entries in the profile can help show areas that can be
-collapsed with even more generic rules. After doing that and making a
-few rules slightly more generic, we end up with:
-
-\begin{small}
-\begin{verbatim}
- /usr/lib/firefox/firefox.sh {
- /bin/basename rmix,
- /bin/bash rmix,
- /bin/gawk rmix,
- /bin/netstat rmix,
- /dev/log w,
- /dev/null rw,
- /dev/tty rw,
- /dev/urandom r,
- /etc/fonts/** r,
- /etc/ld.so.cache rm,
- /etc/localtime r,
- /etc/magic r,
- /etc/opt/gnome/** r,
- /etc/passwd r,
- /etc/resolv.conf r,
- /home/*/.fontconfig/** r,
- /home/*/.gconfd/* rw,
- /home/*/.gconf/ r,
- /home/*/.gconf/* rw,
- /home/*/.gnome2_private/ w,
- /home/*/.mozilla/** rw,
- /home/*/.Xauthority r,
- /lib/ld-2.5.so rmix,
- /lib/lib*.so* rm,
- /opt/gnome/lib/GConf/2/gconfd-2 rmix,
- /opt/gnome/lib/**.so* rm,
- /proc/meminfo r,
- /proc/net/ r,
- /proc/net/* r,
- /tmp/gconfd-*/ r,
- /tmp/gconfd-*/** rwl,
- /tmp/orbit-*/ w,
- /tmp/orbit-*/* w,
- /tmp/ r,
- /usr/bin/file rmix,
- /usr/lib/browser-plugins/ r,
- /usr/lib/browser-plugins/** rm,
- /usr/lib/firefox/firefox-bin rmix,
- /usr/lib/firefox/firefox.sh r,
- /usr/lib/firefox/** r,
- /usr/lib/firefox/**.so rm,
- /usr/lib/gconv/** r,
- /usr/lib/gconv/*so m,
- /usr/lib/lib*.so* rm,
- /usr/lib/locale/** r,
- /usr/share/** r,
- /var/cache/fontconfig/* r,
- /var/cache/libx11/compose/* r,
- /var/run/dbus/system_bus_socket w,
- /var/run/nscd/passwd r,
- /var/run/nscd/socket w,
- /var/tmp/ r,
- }
-\end{verbatim}
-\end{small}
-
-
-\begin{thebibliography}{XX}
-
-\bibitem{apparmor}
-AppArmor documentation,
-\url{http://www.novell.com/documentation/apparmor/}
-
-\bibitem{ols06-pai}
-Al Viro and Ram Pai:
-{\em Shared-Subtree Concept, Implementation and Applications in Linux,}
-Ottawa Linux Symposium, July 19-22, 2006,
-\url{http://www.linuxsymposium.org/2006/}
-
-\bibitem{dragon86}
-Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman:
-{\em Compilers: Principles, Techniques, and Tools}
-(The ``Dragon Book''), Addison-Wesley, 1986, ISBN 0-201-10088-6.
-
-A second edition of this classic is available since August 2006 as
-ISBN 0-321-48681-1.
-
-\end{thebibliography}
-
-\end{document}
-% vim:textwidth=72
diff --git a/v2019.2.tar.gz b/v2019.2.tar.gz
new file mode 100644
index 0000000..c1187fc
--- /dev/null
+++ b/v2019.2.tar.gz
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:a76066632ebe416c770a2ce345d670da846e9f3d89632d6acd6e57fa6b4e264a
+size 1118672