summaryrefslogtreecommitdiffstats
path: root/sechecker/modules/template/profiles.readme
blob: f781ee002baade158b36bc58c5d34eb5b011188c (plain)
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
How to write a profile for SEChecker
=====================================

Table of Contents
========================
1. Use of Profiles
2. Format of the Profile
   2.0 <sechecker>
   2.1 <profile>
   2.2 <module>
   2.3 <output>
   2.4 <option>
3. Example Profile

1. Use of Profiles
==========================
SEChecker has a wide variety of modules which perform various tests
on the policy and/or system.  To make the management and running of 
these modules easier, several profiles are defined.

A profile is used to run a set of modules with options set in a way 
that the resulting report reflects a specific security goal.

To write your own profile, create a new XML file named <profile name>.prof.
The format of the file is detailed below.

2. Format of the Profile
=========================
A profile is an XML file loaded by SEChecker to run a specific set of tests.
The profile recognizes the following tags

2.0 <sechecker>
===========================
The sechecker tag should be the first open tag in the file and the final
tag to be closed.  The tag has a single attribute version, which should 
be set to the current version of SEChecker you are using. To find your 
version number, run: "sechecker --version".

<sechecker version="1.0">

Be sure to remember to close this tag at the end of the file.

2.1 <profile>
===========================
The profile tag tells the parser that SEChecker should interpret this 
file as a profile.  This tag has no attributes.

<profile>

Close this tag just before the sechecker tag is closed at the end of the file

2.2 <module>
===========================
The module tag tells SEChecker that a particular module should be run for
this profile.  The only attribute is name.

<module name="mod_name">

This tag is closed after all other tags related to that module

2.3 <output>
=========================
The output tag tells SEChecker to use this output format for the module
in which it appears. This tag is optional and has one attribute, value.

<output value="short"/>

This tag should close itself.  The valid values are:
   none     -  do not print anything in the report; only run this module
               as dependency of another module.
   quiet    -  print only the stats and header in the report
   short    -  print the header, stats, and a list of items found by the
               module without any accompanying proof
   long     -  print the header, stats, and a list of items found by the 
               module with proof of the result following each item
   verbose  -  print all possible output including the header, stats,
               a list of items and a list of items with proof

NOTE: any of the above values other than "none" are overridden by the
      command line output flags.  Setting an output value in a profile
      overrides the default setting in the configuration file for this
      profile only.

2.4 <option>
=======================
The option tag allows a profile to specify additional options for a module.
The option tag has two mandatory attributes, "name" and "value".
The values of these attributes is specific to the module for which the
option is specified.  Options specified in a profile are used in addition 
to those in the configuration file.

<option name="option_name" value="some_value"/>

This tag closes itself.  As its name implies this tag is optional. 

3. Example Profile
======================
The following is a brief example of a profile 

<sechecker version="1.0">
<profile>

   <module name="mod1">
   </module> 

   <module name="mod2">
      <output value="none"/>
      <option name="attribute" value="my_attrib"/>
   </module> 

   <module name="mod3">
      <option name="foo" value="bar"/>
   </module> 

   <module name="mod4">
      <output value="short"/>
   </module> 

   <module name="mod5">
      <output value="quiet"/>
      <option name="type" value="shadow_t"/>
   </module> 

</profile>
</sechecker>

The result of this profile would be:
-  run mod1 with default configuration;
   print with default settings
-  run mod2 with the additional attribute my_attrib,
   but don't print its results
-  run mod3 with option foo set to bar (in addition to any other settings);
   print with default settings
-  run mod4;
   print in short output 
-  run mod5 with additional type shadow_t;
   print using quiet output

If there are also modules mod6 and mod7, neither would be run unless 
one of the other modules (mod1-5) had a dependency on them.