Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]

["Indan Zupancic" <indan@nul.nu>]

On Thu, January 19, 2012 17:04, Jamie Lokier wrote:
> Andi Kleen wrote:
>> > Not everybody. There are programs which try hard to distinguish between
>> > int80 and syscall. One such example is a sandbox for programming contests
>> > I wrote several years ago. It analyses the instruction before EIP and as
>> > it does not allow threads nor executing writeable memory, it should be
>> > correct.
>>
>> There are other ways to break it, like using the syscall itself to change
>> input arguments or using ptrace from another process and other ways.
>>
>> Generally there are so many races with ptrace that if you want to do
>> things like that it's better to use a LSM. That's what they are for.
>
> I could see the LSM approach working *if* there was an LSM module to
> make it available to unpriviledged userspace.  I.e. a replacement for
> ptrace() for this purpose.
>
> It would be nice to be able to trace and check syscall strings properly.

With current ptrace you can do exactly that. It's just very slow, because
you have to copy the data word by word via PTRACE_PEEKDATA. But if Linux
would support something like BSD's PT_IO ptrace request, then it could be
limited to one extra ptrace command. (PTRACE_STRNCPY would be handy.)

After the check we memcpy the data to a shared read-only mapping, but
that's very quick. We could read the data directly into the RO area,
but as we're mostly dealing with path strings it seemed more efficient
to allocate the needed memory instead of the max every time.

No matter how you make it available to userspace via some LSM, you will
end up with the same context switch overhead ptrace suffers, so I don't
see how a LSM module would give either more options or make it much faster
compared to ptrace.

Greetings,

Indan