@@ -238,6 +238,8 @@ allowx
Specifies the access allowed between a source and target type using extended permissions. Unlike the [`allow`](cil_access_vector_rules.md#allow) statement, the statements [`validatetrans`](cil_constraint_statements.md#validatetrans), [`mlsvalidatetrans`](cil_constraint_statements.md#mlsvalidatetrans), [`constrain`](cil_constraint_statements.md#constrain), and [`mlsconstrain`](cil_constraint_statements.md#mlsconstrain) do not limit accesses granted by [`allowx`](cil_access_vector_rules.md#allowx).
+Note that for this to work there must *also* be valid equivalent [`allow`](cil_access_vector_rules.md#allow) rules present.
+
**Rule definition:**
(allowx source_id target_id|self permissionx_id)
@@ -274,18 +276,21 @@ Specifies the access allowed between a source and target type using extended per
These examples show a selection of possible permutations of [`allowx`](cil_access_vector_rules.md#allowx) rules:
+ (allow type_1 type_2 (tcp_socket (ioctl))) ;; pre-requisite
(allowx type_1 type_2 (ioctl tcp_socket (range 0x2000 0x20FF)))
(permissionx ioctl_nodebug (ioctl udp_socket (not (range 0x4000 0x4010))))
+ (allow type_3 type_4 (udp_socket (ioctl))) ;; pre-requisite
(allowx type_3 type_4 ioctl_nodebug)
-
auditallowx
-----------
Audit the access rights defined if there is a valid [`allowx`](cil_access_vector_rules.md#allowx) rule. It does NOT allow access, it only audits the event.
+Note that for this to work there must *also* be valid equivalent [`auditallow`](cil_access_vector_rules.md#auditallow) rules present.
+
**Rule definition:**
(auditallowx source_id target_id|self permissionx_id)
@@ -324,6 +329,7 @@ This example will log an audit event whenever the corresponding [`allowx`](cil_a
(allowx type_1 type_2 (ioctl tcp_socket (range 0x2000 0x20FF)))
+ (auditallow type_1 type_2 (tcp_socket (ioctl))) ;; pre-requisite
(auditallowx type_1 type_2 (ioctl tcp_socket (range 0x2005 0x2010)))
@@ -332,6 +338,8 @@ dontauditx
Do not audit the access rights defined when access denied. This stops excessive log entries for known events.
+Note that for this to work there must *also* be valid equivalent [`dontaudit`](cil_access_vector_rules.md#dontaudit) rules present.
+
Note that these rules can be omitted by the CIL compiler command line parameter `-D` or `--disable-dontaudit` flags.
**Rule definition:**
@@ -370,6 +378,7 @@ Note that these rules can be omitted by the CIL compiler command line parameter
This example will not audit the denied access:
+ (dontaudit type_1 type_2 (tcp_socket (ioctl))) ;; pre-requisite
(dontauditx type_1 type_2 (ioctl tcp_socket (range 0x3000 0x30FF)))
@@ -392,7 +401,7 @@ Note that these rules can be over-ridden by the CIL compiler command line parame
</colgroup>
<tbody>
<tr class="odd">
-<td align="left"><p><code>neverallows</code></p></td>
+<td align="left"><p><code>neverallowx</code></p></td>
<td align="left"><p>The <code>neverallowx</code> keyword.</p></td>
</tr>
<tr class="even">
Clearly state that allowx, auditallowx and dontauditx only works if there are allow, auditallow and dontaudit equivalent rules respectively. Also fix the examples. Signed-off-by: Dominick Grift <dominick.grift@defensec.nl> --- v3: this actually also applies to allowx (but not to neverallowx) There is something wrong though as for example (dontauditx a b (ioctl file (c))) will also dontauditx for example (dontauditx a b (ioctl file (d))) In other words it seems that you cannot dontauditx individual ioctl if source, target and target class are the same. Same probably applies to auditallowx (unverified) secilc/docs/cil_access_vector_rules.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)