/usr/share/doc/samhain/manual.html/change-control-integration.html is in samhain 4.1.4-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 8. Change Control Process Integration</title><link rel="stylesheet" type="text/css" href="docbook.css"><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><link rel="home" href="index.html" title="The Samhain Host Integrity Monitoring System"><link rel="up" href="index.html" title="The Samhain Host Integrity Monitoring System"><link rel="prev" href="calling-external-programs.html" title="3. Calling external programs"><link rel="next" href="ccp-limitations.html" title="2. Limitations"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><!--#if expr="! ($HTTP_USER_AGENT = /MSIE/)"--><!--#include virtual="/resources/ssi/header.html"--><!--#endif--><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 8. Change Control Process Integration</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="calling-external-programs.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ccp-limitations.html">Next</a></td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="change-control-integration"></a>Chapter 8. Change Control Process Integration</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="sect1"><a href="change-control-integration.html#use-cases">1. Use cases</a></span></dt><dd><dl><dt><span class="sect2"><a href="change-control-integration.html#use-cases-large-patch">1.1. Case I: Machine taken offline for a large patch</a></span></dt><dt><span class="sect2"><a href="change-control-integration.html#use-cases-new-package">1.2. Case II: Installation of a new package</a></span></dt><dt><span class="sect2"><a href="change-control-integration.html#use-cases-config-change">1.3. Case III: Configuration change / Package upgrade</a></span></dt></dl></dd><dt><span class="sect1"><a href="ccp-limitations.html">2. Limitations</a></span></dt></dl></div><p>
<span class="application">samhain</span> 4.0 introduces
a set of new features to allow seamless integration with an
existing change control process.
This feature set has been drafted as the result of a workshop, and is
designed to meet some key criteria:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
The whole procedure can be run in an automated way,
i.e. it can be executed by scripts and without human intervention,
once a
<span class="emphasis"><em>list of affected files</em></span> is available.
It is expected that the change control process will yield the
list of affected files from the
development or quality assurance stage.
</p></li><li class="listitem"><p>
The feature set provided should be rather generic and
not tied to any particular change control software.
</p></li><li class="listitem"><p>
Immediately before a change is implemented, the affected
files can be tested for their integrity. I.e. it can be
verified that the system is in a
<span class="emphasis"><em>known-good</em></span> state before the change
is put into effect.
</p></li><li class="listitem"><p>
After a change is implemented, the baseline, i.e. the
database of known-good file signatures,
can be updated.
</p></li><li class="listitem"><p>
The approval of the change(s) performed
can be <span class="emphasis"><em>securely</em></span>
communicated to the running Samhain daemon
on the affected machine(s), such that a subsequent
file integrity check will raise no alerts.
</p></li></ol></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="use-cases"></a>1. Use cases</h2></div></div></div><p>
The following list shows the use cases that were considered,
and how they may be handled.
</p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="use-cases-large-patch"></a>1.1. Case I: Machine taken offline for a large patch</h3></div></div></div><p>
This case is best handled by a comple re-initialisation of the
baseline database. The running Samhain daemon performs
an on-demand file system scan immediately before the machine
is taken offline to ensure a valid state, the database will
be initialized after the patch has completed, and the Samhain
daemon will re-start when the machine goes online again.
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Before taking the machine offline, a SIGTTOU
signal is sent to
the Samhain daemon to request a file check:
<pre class="programlisting">
sh# kill -s TTOU $( cat /var/run/samhain.pid )
</pre>
It is possible to perform a wait-on-completion (with an optional
timeout) that provides an exit status to indicate whether the
file system scan found any inconsistencies:
<pre class="programlisting">
sh# samhain -w <timeout>
</pre></li><li class="listitem">The machine is taken offline for patching
(e.g. by switching to
another runlevel), and Samhain is shut down.</li><li class="listitem">After the patch, a new baseline is initialized:
<pre class="programlisting">
sh# samhain -t init
</pre></li><li class="listitem">The new baseline is transferred to the server
and the Samhain
daemon restarts when the machine is taken online again.</li><li class="listitem">There may be no feedback between different parts of the
process that implements the change, thus the new baseline
may not be available yet at restart. Therefore Samhain has an
option to delay the download of the baseline at startup:
<pre class="programlisting">
# Delay database download at startup by N seconds
StartupLoadDelay = N
</pre></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="use-cases-new-package"></a>1.2. Case II: Installation of a new package</h3></div></div></div><p>
In this case, because the package is not installed yet
a "pre-flight" scan
may be deemed unneccessary.
After installation of the package,
a <span class="emphasis"><em>DeltaDB</em></span>
(delta database)
containing the added files will be generated and transferred to
the server. There, it will be merged into the
existing baseline database.
</p><p>
The <span class="emphasis"><em>approval</em></span> of the file system changes
will be done by the server
asking the client to download the DeltaDB. For security,
there is no client-side
mechanism to trigger an approval of the file system changes.
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">The list of files (package content + files affected by
pre-/postinstall scripts) is generated in the QA stage.</li><li class="listitem">The package is installed.</li><li class="listitem">Based on the list of files, a
<span class="emphasis"><em>DeltaDB</em></span> (delta database)
is generated:
<pre class="programlisting">
sh# samhain --outfile <DeltaDB> --create-database <file_list>
</pre><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: File list"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="stylesheet-images/note.png"></td><th align="left">File list</th></tr><tr><td align="left" valign="top"><p>
One pathname per line, optionally preceded by a '+' (plus) sign
which, if present, indicates that the
<span class="emphasis"><em>content</em></span> of the file should be stored.
The configuration file will
<span class="emphasis"><em>NOT</em></span> be read, and the policy recorded in
the baseline database will be ReadOnly.
</p></td></tr></table></div></li><li class="listitem">The DeltaDB is transferred to the server data directory,
renamed with a fixed scheme of the form
<baseline_file>.<UUID>,
and merged with the baseline database.
The <span class="emphasis"><em>merging</em></span> function
is provided as part of the Beltane II software:
<pre class="programlisting">
sh# beltane_update --merge <UUID> --update <baseline_file>
</pre></li><li class="listitem">The Samhain server (yule) is advised to inform
the Samhain client
that a DeltaDB of approved changes is available for download:
<pre class="programlisting">
sh# yulectl -c DELTA:<UUID> <client_fqdn>
</pre><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Location and naming scheme"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="stylesheet-images/note.png"></td><th align="left">Location and naming scheme</th></tr><tr><td align="left" valign="top"><p>
The DeltaDB must be named
file.<em class="replaceable"><code>client_fqdn</code></em>.<em class="replaceable"><code>UUID</code></em>
and must be located in the yule data directory,
i.e. the same directory where the baseline database
file.<em class="replaceable"><code>client_fqdn</code></em>
is located. The client will
<span class="emphasis"><em>only ask for the UUID</em></span>.
Similar to the baseline database, the
pathname of the file is constructed by the server,
using the client FQDN and the requested
<em class="replaceable"><code>UUID</code></em>.
</p></td></tr></table></div></li><li class="listitem">The client receives the UUID and
requests the DeltaDB from the server. In case of a
failure, re-trying is controlled
by the following two configuration options:
<pre class="programlisting">
# Maximum retry count
SetDeltaRetryCount = N
# Time in seconds between re-tries
SetDeltaRetryInterval = N
</pre></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="use-cases-config-change"></a>1.3. Case III: Configuration change / Package upgrade</h3></div></div></div><p>
This case differs from Case II insofar as there are already
installed files, and therefore
it is desirable to verify the integrity of those files
before the change is put
into effect. To perform this check, on the server
a <span class="emphasis"><em>PartialDB</em></span> (partial database,
containing only data for affected files)
is generated from the full baseline database. This
PartialDB is then transferred to the
client and used to perform a verification scan.
</p><p>
If the affected files are found to be in a consistent state,
the procedure continues as in Case II then.
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">The list of affected files is generated
in the QA stage.</li><li class="listitem">On the Samhain server, a
<span class="emphasis"><em>PartialDB</em></span>
(partial baseline database) for the affected files
is generated from the complete baseline:
<pre class="programlisting">
sh# samhain --outfile <PartialDB> --list-filter <list_file> --binary -d <baseline_file>
</pre></li><li class="listitem">The PartialDB is transferred to the client.</li><li class="listitem">The integrity of the affected files is verified before
the change is implemented (success or failure
indicated by exit status):
<pre class="programlisting">
sh# samhain --verify-database <PartialDB>
</pre></li><li class="listitem">After successful verification, the process
continues as in Case II.</li></ol></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="calling-external-programs.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ccp-limitations.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">3. Calling external programs </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 2. Limitations</td></tr></table></div><!--#if expr="! ($HTTP_USER_AGENT = /MSIE/)"--><!--#include virtual="/resources/ssi/footer.html"--><!--#endif--></body></html>
|