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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
