This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

arch paper section on safety


Before I check this in I was hoping to get through
one round of review.

Brad

=================================================================

Safety in Systemtap

Systemtap is designed to be safe to use on production systems. 
An implication is that it should be extremely difficult if not
impossible to disable or crash a system through use or misuse of 
Systemtap. Problems like infinite loops, division by zero, and 
illegal memory references should lead to a graceful failure of 
a Systemtap script without otherwise disrupting the monitored
system. At the same time, we'd like for Systemtap extensions to
compile to machine code, to leverage existing infrastructure such
as compilers and "insmod" and to approach native performance.

Our basic approach to safety is to design a safe scripting language, 
with some safety properties supported by runtime checks. Systemtap 
compiles the script file into native code and links it with the 
systemtap runtime library to create a loadable kernel module. 
Version checks and symbol name checks are applied by insmod 
[I ASSUME WE GET THE SAME SAFETY HERE AS /sbin/insmod].
The elaborator generates instrumentation code that gracefully 
terminates loops and recursion at runtime if they run beyond a 
configurable threshold.
We avoid priviledged and illegal kernel instructions by excluding
constructs in the script language for inlined assembler, and by
using compiler options commonly used for the kernel.

Systemtap safety also requires controling access to kernel memory. 
By default, kernel code cannot be invoked directly from a Systemtap 
script. The Systemtap runtime can use kernel subroutines, and
these references are assumed to be safe.
Systemtap provides special language features for referring to 
external data. [PROBLEM: POINTER ARGUMENTS TO PROCEDURES] When 
it sees such references, it constrains it based on a policy 
specified when the script is run. By default, writes to arbitrary 
kernel memory are prohibited, and external reads of any kernel 
memory are allowed except for the range of the virtual address 
space used for memory-mapped devices.
To implement these restrictions, external writes cause the
elaborator to generate an error, and checking code is inserted 
to enforce range restrictions on external read references.
Additionally, a modified trap handler is used to safely handle
invalid memory references anywhere in the kernel address space.
Systemtap also supports a "guru" mode where these code and data
reference constraints are removed. This allows us to tradeoff 
safety features to support the needs of kernel debugging tasks.

Safety Enhancements

We are considering a number of subsystems that extend the safety
and flexibility of Systemtap to match and exceed that of other
systems based on interpreters.
A memory and code "portal" would direct external memory 
references from Systemtap scripts, both to code and data, 
through a special-purpose interpeter or "portal."
The goal of the portal is to shift safety policy selection 
to the script user rather than the script author, and to 
support definition of safety policies by script users, 
giving them explicit and finer-grained controls.
We anticipate a model where people commonly use scripts 
written by others. 
Trivial policies would be provided with the system to support 
"guru" (no restrictions) and default modes (restricted external
write and code access).
Other simple policies would expand access for a script incrementally.
For example, you might allow external calls to an explicit list 
of kernel subroutines, or writes to an explicit list of kernel
data structures or range of kernel memory addresses. Such policies 
would expand script capabilities with better safety than guru mode. 
Eventually, the policy subsystem might be extended to support 
security goals, such as restricting memory access control based 
on UID.

A optional static analyzer provides redundant checking and 
protection against various system bugs, installation problems and 
misuse. The static analyzer examines a disassembled kernel module 
and confirms that it satisfies certain safety properties. Simple
checks include disallowing priviledged instructions and instructions
that are illegal in kernel mode. More elaborate checks confirm that 
loop counters, memory portals and other safety features are used, 
given minimal cooperation from the language implementation to make 
the machine code checkable. The analyzer rejects uncheckable code.

Comparision to Other Systems

Solaris DTrace includes a number of unusual features intended to
enhance the safety and security of the system. These features include:
- very restricted scripting language. The D language does not support
  procedure declarations or a general purpose looping construct. This
  avoids a number of safety issues in scripts including infinite
  loops and infinite recursion.
- interpreted language. The D scripts compile to a RISC abstract
  machine language that executes in an interpreter embedded in the
  Solaris kernel. Because D scripts are interpreted rather than
  executed directly, it is impossible for them to include illegal or
  priviledged instructions or to invoke code outside of the DTrace
  execution environment. The interpreter can also catch invalid
  pointer dereferences, division by zero, and other run-time errors.
Features such as these enhance the perceived safety of DTrace.

Systemtap will support kernel debugging features that DTrace does not,
including ability to write arbitrary locations in kernel memory and
ability to invoke arbitrary kernel subroutines.

Since the language infrastructure used by Systemtap is common to
all C programs, it may be better tested and more robust than the
special-purpose infrastructure used by DTrace.

The embedding of an interpreter in the Solaris kernel represents
significant additional kernel functionality. This introduces an
increased risk of kernel bugs that could lead to security or
reliability issues.

Like DTrace, DProbes uses an interpreted language. [would a DProbes
expert like to finish this part?]

SECURITY

I'm not convinced we have anything important to write here.

Goals: 
- Prevent systemtap user from creating new system vulnerabilities
- Stretch: appropriate access controls for non-root users

Assumptions: systemtap user has root priviledges
Conclusion: nothing locally to protect at this time


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]