This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: separating policy and mechanism
- From: "Chen, Brad" <brad dot chen at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Mon, 2 May 2005 18:19:04 -0700
- Subject: RE: separating policy and mechanism
> Sure, we
> might want the user to have more fine-grained control over operation
> permissions, once we define such opportunities.
The memory portal is the specific mechanism I've suggested.
I'd like to hear other suggestions from yourself or our
collaborators.
As far as expression of policy goes, I'm definitely not
satisfied with something as coarse as the command-line
switch you suggest below. If we think this is worth doing
I'm hoping we'd aspire to something with significantly
better transparency and flexibility. For example, a
hypothetical policy configuration file might support
options like this:
Kernel-Writes: deny all
Kernel-Reads: allow if USER==$UID
Kernel-Calls: allow by symbol
sys_read()
sys_write()
sys_open() with user==$UID
I assume these restrictions would apply only to code
created by the script author; the tapsets and runtime
would be considered "trusted"; effectively like part of
the OS. Clearly there is a huge amount of work implied
by such options; I'm trying to communicate a vision, not
a May deliverable. None-the-less some of the simpler
features would be easy to provide with the portal.
Brad
-----Original Message-----
From: Frank Ch. Eigler [mailto:fche@redhat.com]
Sent: Tuesday, April 26, 2005 3:38 PM
To: Chen, Brad
Cc: systemtap@sources.redhat.com
Subject: Re: separating policy and mechanism
Hi -
brad.chen wrote:
> Separation of policy from mechanism is an established tenet
> of Unix system development. [...]
Indeed, it is a well known design principle: just abstract as the
concepts of "design" versus "implementation". The missing link is
making it relevant to systemtap by mapping the terms to our peculiar
domain.
For example, by "mechanism" one might refer to the dispersed body of
code that will enforce the union of safety issues, and by "policy" one
might refer to the provision of a command line switch and its global
variable to pick a translation mode. There is a "separation" by
definition, but it's kind of trivial, and is not the kind that the
portal/static-checker ideas require.
Since they depend on one's point of view, the uses of the term "safety
policy" and "safety mechanism" in your key questions list are not
dispositive about any particular implementation strategy. Sure, we
might want the user to have more fine-grained control over operation
permissions, once we define such opportunities. But that says nothing
about whether the enforcement of such permissions must take place with
regard to a separation boundary of any particular nature.
- FChE