The linux security features are that the untrusted code is in an interpreted language running under seccomp, with syscalls mediated by a seccomp-like utrace policy, inside a restrictive linux container, and under a restrictive AppArmor profile.
... crikey. In a good way.
Can it make direct system calls to the host windows OS, bypassing the linux access policies?
Well, the answer to this depends on how you are visualising and a few other factors - which really needs a "how does virtualisation work" explanation to cover it.
Assuming Intel-VT, I've covered in a bit of depth (plus links) virtualisation here. As a very brief summary, your host does the usual operating system things - page tables, call gate decriptors. Then to run a virtual machine the host sets up another table for describing vms including a memory map for the vm and then runs a VMXON instruction - and then the VM is created.
From the perspective of the virtual machine, the memory it is presented is the whole system memory available to it - the same idea as virtual memory for a normal application. Under normal virtualisation scenarios you do not present the same memory your host runs on to the guest - you give it its own space which means it cannot directly reach any of your existing setup.
However, if you could map host memory to the guest, to make a host system call directly you'd need to be able to raise an interrupt registered with the host. Here's a fairly good internals of NT document - it's different enough from Windows that to actually implement this would probably require modifying your kernel and I'd be reasonably confident in saying that if you exposed the memory as is, you'd either break Windows, or you'd break Linux. This is, of course, assuming you map your host memory into the guest virtual machine... I might not be being very clear, so to say exactly what the problem is - linux has registered int 80 (or is using sysenter); Windows is registering int 2e or sysenter (another good article - same author as the previous one)). They could definitely register different software interrupt handlers if either had the other free... but sharing sysenter would be impossible without modification - and that's just a problem with memory locations. Things get even stickier when we talk about calling conventions...
We're not quite out of the woods yet though. Whilst you cannot directly easily without some serious engineering to modify the platforms involved call the host's system calls clearly there needs to be some way to communicate with the host some of the time. There is - a VMCall instruction (in the guest) causes a VMExit to the host with info exchange so the host can provision a request - if there are any vulnerabilities here, you might indirectly be able to call a system call, or call(s). These happen whenever you and the host need to share something other than the CPU and memory. Intel VT-d is an effort to provide DMA as needed in hardware, circumventing the need for VMCalls for some classes of device.
Things are slightly different if you do software virtualisation. To provide the same thing you have to write a CPU emulator - however, this is a host-running process and thus if you can inject code and execute it, you can call a system call in the context of whatever permissions the emulator has. This is comparable (very loosely, sort of, disclaimer: metaphorically speaking) to a bug in the JVM - a malformed piece of java bytecode that can inject shellcode into the VM is going to do nasty things, no matter the security provided by the JVM.
I should add the obvious here - I'm talking about engineering and virtual machine problems. If you set up a samba share and double click dodgy.exe that was provided by your malicious code, it's game over. It sounds like that's an obvious statement for you - but just in case other people think VMs solve all their problems... not quite.
Various references:
tl;dr
It would be very difficult (to the point of verging on rebuilding parts of the OSes) in hardware-based virtualisation to directly call a system call belonging to the host from the guest; even more so when they use different OSes. Exploits are possible indirectly, but then require vulnerabilities in the hypervisor code or its usage.
