This file is indexed.

/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 &lt;timeout&gt;
	  </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 &lt;DeltaDB&gt; --create-database &lt;file_list&gt;
	  </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
	  &lt;baseline_file&gt;.&lt;UUID&gt;,
          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 &lt;UUID&gt; --update &lt;baseline_file&gt;
	  </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:&lt;UUID&gt; &lt;client_fqdn&gt;
	  </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 &lt;PartialDB&gt; --list-filter &lt;list_file&gt; --binary -d &lt;baseline_file&gt;
	  </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 &lt;PartialDB&gt;
	  </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>