Information Technology Reference
In-Depth Information
•
Membership template (var
€ {
a, b, c
}
)
.
This template corresponds to invariants
that state that var only acquires a fixed set
of values (in this case, a, b or c). If this
set is a singleton
{
a
}
, denoting that var is a
constant, then Daikon expresses the invari-
ant as var == a.
violate invariants that conform to other kinds of
templates, we may need to extend Gibraltar with
more templates in the future. Fortunately, Daikon
supports an extensible architecture. Newer invari-
ant templates can be supplied to Daikon, thereby
allowing Gibraltar to detect more attacks.
the monitor
•
Non-zero template (var != 0).
The non-
zero template corresponds to invariants
that determine that a var is a non-NULL
value (or not 0, if var is not a pointer).
During enforcement, the monitor ensures that the
data structures in the target's memory satisfy the
invariants obtained during training. As with the
invariant generator, the monitor obtains snapshots
from the data structure extractor, and checks the
data structures in each snapshot against the invari-
ants. This ensures that any malicious modifications
to kernel memory that cause the violation of an
invariant are automatically detected.
•
Bounds template (var <= const), (var
>=
const).
This template corresponds to
invariants that determine lower and upper
bounds of the values that var acquires.
The three example templates discussed above
correspond to invariants over variables and fields
of C struct data structures. These invariants can
be inferred over individual objects, as well as
over collections of data structures (e.g. the fields
bar of all objects of type struct foo have value 5).
Invariants over collections describe a property
that hold for
all members
of that collection across
all snapshots
.
persistent vs. transient invariants
The invariants inferred by Gibraltar can be catego-
rized as either
persistent
or
transient
. persistent
invariants represent properties that are valid across
reboots of the target machine, provided that the
target's kernel is not reconfigured or recompiled
between reboots. All the examples in Figures 11-
15 are persistent invariants.
An invariant is persistent if and only if the
names of the variables in the invariant persist
across reboots
and
the property represented by the
invariant holds across reboots. Thus, a transient
invariant either expresses a property of a variable
whose name does not persist across reboots or
represents a property that does not hold across
reboots. For example, consider the invariant in
Figure 10, which expresses a property of a
struct
file operations object. This invariant is transient
because it does not persist across reboots. The
name of this object changes across reboots as it
appears at different locations in kernel linked lists;
consequently, the number of
next
and
prevs
that
appear in the name of the variable differ across
reboots.
•
Length template (length(var) == const).
This template describes invariants over
lengths of linked lists.
•
Subset template (coll1 TODO-SUBSET
coll2)
. This template represents invariants
that describe that the collection coll
1
is a
subset of collection coll
2
. This is used, for
instance, to represent invariants that de-
scribe that every element of one linked list
is also an element of another linked list.
The last two example templates are used to
describe properties of kernel linked lists. As re-
ported in section 4, in our experiments, invariants
that conformed to the Daikon templates sufficed
to detect all the conventional and the modern
stealth attacks on the kernel that we tested.
However, to accommodate for rootkits that only
Search WWH ::
Custom Search