Re: user space target symbol dereferencing

[fche at redhat dot com (Frank Ch. Eigler)]

mjw wrote:

> [...]  Then we thought it might just work directly by guessing
> whether the target symbol/dereferenced pointer is in user space
> using the existing constructs and do a set_fs(USER_DS) and then an
> access_ok() to see if it a pointer already in user space. But that
> would basically just add overhead without really adding new
> functionality.

Right.

> Also someone could "spoof" a pointer in kernel space (say as
> argument to a syscall) getting around any user space access checks
> you would like to see done.

And probably here is the reason why this is an interesting issue.  If
the consequences of a "__user"-declared pointer with a bad value were
nothing more than garbage data showing safely up in trace output, that
might be OK.  But what if it's not garbage, but a deliberate attempt
to extract privileged data (use of a trusted script by e.g. a
stapusr-level person, running it against a system running malevolent
programs), this is a problem.

So it seems we need a way for the tapset and $expressions to *assert*
that a particular link in the pointer chain is supposed to be a __user
pointer.  The proposed explicit typecasting operation (bug #5634)
could represent that for the latter: @cast("__user char *", $var)[0]
that could expand to a parallel suite (uderef / uread_TYPE?) of
runtime functions.

> While trying some of the above out I happily mistyped things and saw
> that deref() just works fine because set_fs(KERNEL_DS) doesn't
> actually constrain the addresses to kernel space.

(Right, but   set_fs(KERNEL_DS); flag1=access_ok(ptr);
              set_fs(USER_DS); flag2=access_ok(ptr); 
              kernel_space_proper = flag1 && !flag2; ).

> Is this true for all architectures? If so and we don't need/want any
> "type safety" on user space access checks we could just rewrite most
> things in aux_syscalls.stp by direct dereferencing through -> and []
> anyway.

We could go with this assumption - (subject to bug #1288 (timoore)).


- FChE