New Probe Points for Unprivileged Users

New Probe Points for Unprivileged Users

[Dave Brolley]

Hi,

Support for limited probing by unprivileged users (not root, stapdev or 
stapusr) was recently pushed to our git sources (see the NEWS file). The 
number and type of probe points available to these users has 
intentionally been restricted in the early stages of development and 
testing.

Overall, the philosophy is that an unprivileged user should not be able 
to use systemtap to affect the system in ways they would not normally be 
able to or to obtain information that they would not normally be able to 
obtain.

The current set of allowed probes is:

begin
begin(N)
end()
end(N)
error
error(N)
never
timer.*
process.begin
process.end
process("xxx").begin
process("xxx").end
process(N).begin
process(N).end

where process.* probes are restricted to the user's own processes.

I would like to expand the list of available probes to include the 
remainder of the process.* probes where, once again, probes are 
restricted to the user's own processes. Before doing so, I just wanted 
to double check that this would not be exposing anything in violation of 
the philosophy mentioned above. If you see any problems with exposing 
the probe points below to unprivileged users, for their own processes, 
then please let me know.

Thanks,
Dave
-------------------------------------
process.syscall
process.syscall.return
process.thread.begin
process.thread.end
process("xxx").function("yyy")
process("xxx").function("yyy").inline
process("xxx").function("yyy").call
process("xxx").function("yyy").return
process("xxx").function("yyy").return.maxactive
process("xxx").function("yyy").label("lll")
process("xxx").function(N)
process("xxx").function(N).inline
process("xxx").function(N).call
process("xxx").function(N).return
process("xxx").function(N).return.maxactive
process("xxx").insn
process("xxx").insn.block
process("xxx").mark("mmm")
process("xxx").mark(N)
process("xxx").statement("yyy")
process("xxx").statement(N)
process("xxx").syscall
process("xxx").syscall.return
process("xxx").thread.begin
process("xxx").thread.end
process(N).statement(N).absolute
process(N).statement(N).absolute.return
process(N).insn
process(N).insn.block
process(N).syscall
process(N).syscall.return
process(N).thread.begin
process(N).thread.end

Re: New Probe Points for Unprivileged Users

[David Smith]

On 09/10/2009 02:41 PM, Dave Brolley wrote:
> Hi,
> 
> Support for limited probing by unprivileged users (not root, stapdev or
> stapusr) was recently pushed to our git sources (see the NEWS file). The
> number and type of probe points available to these users has
> intentionally been restricted in the early stages of development and
> testing.
> 
> Overall, the philosophy is that an unprivileged user should not be able
> to use systemtap to affect the system in ways they would not normally be
> able to or to obtain information that they would not normally be able to
> obtain.

...

> I would like to expand the list of available probes to include the
> remainder of the process.* probes where, once again, probes are
> restricted to the user's own processes. Before doing so, I just wanted
> to double check that this would not be exposing anything in violation of
> the philosophy mentioned above. If you see any problems with exposing
> the probe points below to unprivileged users, for their own processes,
> then please let me know.

I'll comment on the ones I'm familiar with.  The thread.begin/thread.end
variants should be fine when restricted to the user's own processes.
They are very similar to the process begin/end probes you've already
allowed.  Specifically, I'm talking about the following:

> process.thread.begin
> process.thread.end
> process("xxx").thread.begin
> process("xxx").thread.end
> process(N).thread.begin
> process(N).thread.end

The syscall variants should also be fine when restricted to the user's
own processes.  They will slow down the target task, but since they will
be the user's own processes that should be fine.  They shouldn't reveal
any more information than running 'strace' on a process would.  If that
level of information is OK, then the syscall variants should be OK.

> process.syscall
> process.syscall.return
> process("xxx").syscall
> process("xxx").syscall.return
> process(N).syscall
> process(N).syscall.return

Next we have the 'insn' probe variants.  Like the syscall probes, they
will slow down the target task.  They can provide information similar to
what a user could get by using gdb to single-step his own process.  If
that level of information is OK, then the insn probe variants should be OK.

> process("xxx").insn
> process("xxx").insn.block
> process(N).insn
> process(N).insn.block

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: New Probe Points for Unprivileged Users

[Josh Stone]

On 09/10/2009 12:41 PM, Dave Brolley wrote:
> Hi,
> 
> Support for limited probing by unprivileged users (not root, stapdev or 
> stapusr) was recently pushed to our git sources (see the NEWS file). The 
> number and type of probe points available to these users has 
> intentionally been restricted in the early stages of development and 
> testing.
> 
> Overall, the philosophy is that an unprivileged user should not be able 
> to use systemtap to affect the system in ways they would not normally be 
> able to or to obtain information that they would not normally be able to 
> obtain.
> 
> The current set of allowed probes is:
> 
> begin
> begin(N)
> end()
> end(N)
> error
> error(N)
> never
> timer.*
> process.begin
> process.end
> process("xxx").begin
> process("xxx").end
> process(N).begin
> process(N).end
> 
> where process.* probes are restricted to the user's own processes.

Something I just realized even in this set -- the address range checks
for accessing user memory are good, but they also must ensure that the
current process memory belongs to the right euid.  In "timer.*"
especially, and probably also in "end" and "error", the user context
could be anything.

> I would like to expand the list of available probes to include the 
> remainder of the process.* probes where, once again, probes are 
> restricted to the user's own processes. Before doing so, I just wanted 
> to double check that this would not be exposing anything in violation of 
> the philosophy mentioned above. If you see any problems with exposing 
> the probe points below to unprivileged users, for their own processes, 
> then please let me know.

I think all of the process.* are fine -- there's nothing that couldn't
be gotten by the user through other means (gdb, valgrind, etc.).

I'd like to see semko tests though, to assert that all remaining probe
types are properly refused to unprivileged users.

Thanks,

Josh