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
Gianni Tedesco
2010-Oct-13 15:13 UTC
Re: [Xen-devel] Stop the execution of syscall in trap.c
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
Carlo Maiero
2010-Oct-13 18:37 UTC
Re: [Xen-devel] Stop the execution of syscall in trap.c
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