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]

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


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