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


>> 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.
>
>OK but recall my note during the face-to-face meeting that we need to
>consider people reusing each other's script fragments in a way that
>avoids automatically blessing those reused scripts as trusted. 
I don't see the conflict; re-used code would go into end-user
scripts, not into tapset definitions, and so would not be 
trusted. I'm assuming that creating trusted code would require 
something like building all of Systemtap from source, which 
would not be a normal thing for a script author to do.

Brad

-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Frank Ch.
Eigler
Sent: Tuesday, May 03, 2005 9:54 AM
To: Chen, Brad
Cc: systemtap@sources.redhat.com
Subject: Re: separating policy and mechanism


"Chen, Brad" <brad.chen@intel.com> writes:

> [...]  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

OK.  A tangible first step in this direction will be to get the
translator to print a "security profile" of an elaborated script
program.  This would enumerate the sorts of items you listed: external
references by the script and its dependencies.


> 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.

OK but recall my note during the face-to-face meeting that we need to
consider people reusing each other's script fragments in a way that
avoids automatically blessing those reused scripts as trusted.


> Clearly there is a huge amount of work implied by such options; I'm
> trying to communicate a vision, not a May deliverable. [...]

Fair enough.  Please don't feel discouraged.  I am sure there is a
germ of a good idea in there, even if I don't quite see it yet. ;-)


- FChE


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