Xen devel - Oct 2010 - Stop the execution of syscall in trap.c

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.


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

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


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

2010/10/13 Gianni Tedesco <gianni.tedesco@citrix.com>
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel