Re: [Xen-devel] Stop the execution of syscall in trap.c

[Carlo Maiero <zesster@xxxxxxxxx>]

2010/10/13 Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>

On Wed, 2010-10-13 at 14:11 +0100, Carlo Maiero wrote:
> I'm working on a similar project
> of http://lists.xensource.com/archives/html/xen-devel/2008-11/msg00813.html,
>
>
> but after the interception I also want to stop some syscall from be
> executed by the hypervisor.
>
>
> I intercept the call in the do_guest_trap in trap.c, and i control the
> (cpu_user_regs regs) regs->eax for the number, and if
> the number is some unpermitted syscall as for example (128 for insmod
> or 129 for rmmod), i want to stop the execution of the syscall.
>
>
> How can I stop the execution here?(it's possible to stop the execution
> here?)  or return an error code without a system crush?
> I've tried something but somethings just print the error code, and
> don't stop the syscall execution, and other things brings to panic.

Sounds like you just want to put -EPERM in %eax and not forward the
interrupt to the guest in that case...

By the way, it's difficult to see what threat model this
security-related-looking feature is intended to address.

The guest kernel already implements its own security model - and on a
much finer granularity than syscall number. If an attacker can control
the kernel so as to bypass that security model then it would also be
able to bypass these restrictions, trivially by using sysenter or
setting up a syscall trap at other than 0x80 but also by implementing
any of an infinite variation on kernel/user communication vectors. In
other words, you are better off writing an LSM if all you want to do is
restrict root from modifying the kernel ;)

Gianni

Thanks, it works!! 

This is a work for my thesis. The target of the work is to offer a system that dynamically from dom0 decide, 

from stats and logs, what are the operation permitted and what are the operation not granted.

Maybe sometimes we just want the attacker to run some malicious software (ex. honey pot). 

it's a guideline of the project to keep unchanged the guest.

Carlo

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel