Re: safety paper - please send feedback!

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


On Wed, Mar 23, 2005 at 11:14:15AM -0800, Chen, Brad wrote:
> I've collected some thoughts on Safety in Systemtap for 
> consideration by the group. [...]

Thank you.


> [...]
> CANDIDATE SAFETY GOALS
> [...]
> G1. "Safety" and "Guru" modes: Sets of safety-related features are
>   enabled or disabled using a single option such as a command-line
>   flag. The flag might change the behavior of the compiler, the
>   loader, or the runtime. 

It clear that the translator should enforce as many of these
constraints as possible, before the script processing pipeline
gets any farther.

> G2. Finite loops: Infinite loops cause a script to be safely
>   terminated.
> G3. Finite loops: Systemtap supports only restricted looping
>   constructs that make it impossible to write an infinite loop. 
> G4. Finite recursion: Recursion beyond a pre-defined limit causes a
>   script to be safely terminated.
> G5. No procedures. The scripting language does not support procedure
>   definition. [...]

I don't think G3/G5 are acceptable.  Nor are they necessary, if we
have the same mechanism already used to prevent G2/G4.  Of course
theoretically, iteration==recursion.

> G6. Restricted kernel calls: The system restricts the kernel
>   subroutines that can be invoked directly by a script. [...]

The script should make no direct kernel calls, period: there should
be no syntax for this.  (Perhaps in "guru" mode, there may be an
embedded-C construct that could permit this, but that's beyond the
scope of your paper.)

> G7. No non-Algol control flow. Excludes goto, longjmp [...]

How is this a *safety* issue?  (I'm not proposing to support them
in the script language, but why did you bring it up?)

> [...]
> G9. Restricted reads. Disallows reads as per some policy TBD. For
>   example, user memory read access might be restricted to processes
>   belonging to the user running the script. 

An unprivileged user cannot be allowed to read arbitrary kernel memory
either, as that's an easy way to violate privacy boundaries.

> G10. Remote compilation. Allow scripts to be compiled on one machine
>   for use on a different machine. [...]

How is this a safety issue?

>   [...] DTrace appears to be crashproof. [...]

I wonder if this appearance has been tested much by an aggressive
attempt.


> IMPLEMENTATION OPTIONS FOR SYSTEMTAP SAFETY FEATURES
> [...]
> The compilation system could sign binaries to confirm their source.
> [...]

Since systemtap will be open-source, any *local* cryptographic signing
capability could be easily defanged by an attacker.  This is different
from ordinary kernel module signing, where kernel compilation is
generally done well apart from deployment.


> Static Checking
> [...]
> - Signatures. Check the signature applied by the Systemtap
> compiler. Apart from making taps tamper resistant it would also
> prevent accidental loading of binaries not generated by Systemtap. 

Version checking can be done apart from the signatures.


> [...]
> - Illegal instructions: The tap could be disassembled to confirm that
> it does not include priviledged system instructions or instructions 
> that are not allowed in the kernel (floating point, MMX, SSE, etc.)

But the translator will not emit such stuff, and the same compiler
options will be used as used to build other kernel modules.  So
systemtap kernel objects won't contain such miscreancies unless they
have been tampered with.

> - Illegal external instruction references. The static checker could
> examine external references [...]

Same comments as above.

> - Illegal external data references. The static checker could examine
> memory reference instructions [...]

Same as above, plus memory reads and writes would be hellish or even
impossible to check statically in the general case.  Consider an
attempt to read out some local variable in a breakpointed function.
This operation involves direct poking and dereferencing pointers
within the kernel stack.  I still think you will need to work out a
more realistic example to see what sorts of machine-language-level
operations can be identified as suspect or not.


> - Illegal control flow. The static checker might disallow non-local
> non-procedural control flow. It might disallow backward branches,
> assuming the source language were loop-free.

This restriction is unlikely to be met by the object code.


> [...]
> Language Implementation
> 
> The Systemtap runtime might use a timeout or counting mechanism to
> limit time spent in loops, thereby preventing infinite loops. [...]
> The language implementation might provide a similar counting or
> timeout mechanism to prevent recursion-related faults. [...]

The latter is the intent: the translator would emit the C code that
performs this counting.  (In either case, there would be backward
branches that would render moot a static prevention attempt.)


> [...]
> Extension B: Static Checker
> 
> A static checker confirms safety properties of a compiled Systemtap
> script immediately prior to loading into the kernel. 

There is little advantage to a user-level static checker that enforces
this stuff, unless we're talking only about unprivileged users.  A
root user can load anything into the kernel, bypassing the static
checker with "insmod" by mistake.


> [...]
> M2: systemtap API version mismatch
> M3: systemtap runtime version mismatch

FWIW, I envision the systemtap runtime being actually emitted together
into a single kernel module, eliminating this kind of version mismatch.


> M5: buggy script
> A user who is learning to use Systemtap writes many buggy scripts. 
> Can the we guarentee that the system will never crash? 

We have to identify the various problem scenarios and address them
individually.

> Consider memory leak, 

Without runtime dynamic memory allocation, not a problem.  (mhunt:
this is one of the reasons I'm unhappy with your string storage
scheme in runtime/map.c)

> recursion, infinite loop, 

Already discussed (not expected to be possible).

> stale pointers, bogus pointers,

Pointers are not present in the systemtap script language.  Mechanisms
to dereference target-space pointers will have to be designed to
prevent some classes of problems.

> jumps into arbitrary locations in kernel code, etc.

Already discussed (not expected to be possible).


> M6: a bug in the compiler, translator, runtime
> Does the system crash or just print a warning message?

The possibilities are of course endless. :-)


> [...]
> M8: 3rd party script as a binary form
> M9: 3rd party script as a source file

This is a complicated issue, and worth much specific focus.  I expect
binary kernel objects to not be distributable with sufficient safety.
Sources may be, especially when translated in "safe" mode.

An additional angle worth considering is a mixture of safe/guru mode,
where library script fragments installed in some trusted search path
might get additional privileges from the translator than the
user-specified input file.


> [...]
> M11: malicious attack: corrupted compiler, corrupted script-
> launching system
> We do our users a favor by minimizing the number of software
> components they need to trust or secure in order to make the overall
> system secure.  [...]

I propose we spend little effort protecting against a malicious attack
of this nature.


- FChE