All, Is there any way we can set up a communication channel (not a TCP/IP based network) between domain0 and unprivileged domains. This can be useful in a way that we can write automatic configuration mechanisms for our unprivileged VMs. Illustration: I have a domainU running on a host, which doesn;t have network connectivity (like ssh). I just use the VM as a environment I can issue commands and get results. Ports on domain0 are blocked preventing me from accessing the VM console. I do not have an account in domain0 for security. What can be done is running a truested software on domain0, which takes commands and runs them inside domainU and returns me the results. The bottomline is a communication channel between dom0 and domU. Any ideas? Arijit _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thursday 01 September 2005 22:11, Arijit Ganguly wrote:> All, > Is there any way we can set up a communication channel (not a TCP/IP > based network) between domain0 and unprivileged domains. This can be > useful in a way that we can write automatic configuration mechanisms > for our unprivileged VMs.From what I heard, XenFS will allow that kind of communication, for it will be possibe to mmap a file from it in different domains and have shared memory between domains that way. But thats still far from "running commands" in a target domain, so you''ll still need some application to do that for you... Easiest solution for your problem would be probably a shared directory with dom0 putting shellscripts or executables into, and domU polling that directory, executing and deleting whatever it finds... But it''ll be some time till XenFS will be available...> Illustration: > I have a domainU running on a host, which doesn;t have network > connectivity (like ssh). I just use the VM as a environment I can > issue commands and get results. Ports on domain0 are blocked > preventing me from accessing the VM console. I do not have an account > in domain0 for security. > What can be done is running a truested software on domain0, which > takes commands and runs them inside domainU and returns me the > results. > > The bottomline is a communication channel between dom0 and domU. Any ideas?Well, if its just that you want to "jail" suspicious software started from dom0 in a domU: - mount the domU FS in dom0. - put your app in it, say /bin/something - unmount domU root - patch "init=/bin/something" into your domU config file as kernel param - xm start domU - wait till timeout or shutdown of domU, xm stop it - mount domU Root FS - read results... - maybe use a modified startscript or an entry in inittab instead of the "init=..." kernel param. If you just want to exchange some configuration data on domU, put it onto domU''s kernel commandline, and read it back from /proc/cmdline inside domU But I''d still say that a private bridge between domU and dom0 (not connected to any real network device) and running ssh on it would be a more sensible method. Without routing and maybe some ebtables scripts on it, that bridge would be quite secure. Did you have a look at the vserver kernel patches and tools (http://linux-vserver.org/)? Those might be by far better suited for your problem. HTH /Ernst _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Arijit Ganguly wrote:>All, >Is there any way we can set up a communication channel (not a TCP/IP >based network) between domain0 and unprivileged domains. This can be >useful in a way that we can write automatic configuration mechanisms >for our unprivileged VMs. > >If you look either at the testsuite I wrote for the console daemon (tools/console/testsuite in unstable) or in Dan''s xm-test (http://static.danplanet.com/xm-test/xm-test-0.1.0.tar.gz), you''ll see we''ve both implemented very similiar protocols that allow commands to be executed over a domU''s console from dom0. The natural extension of this (when we get multiple console support) is to dedicate a console channel to something like this that would give you precisely what you''d want. Actually, if I were you, I''d just set up a dummy nic that wasn''t routed outside of dom0 and have ssh bind to only that interface in domU. It''s a bit heavier weight but it gets the job done (in a very robust way). Regards, Anthony Liguori>Illustration: >I have a domainU running on a host, which doesn;t have network >connectivity (like ssh). I just use the VM as a environment I can >issue commands and get results. Ports on domain0 are blocked >preventing me from accessing the VM console. I do not have an account >in domain0 for security. >What can be done is running a truested software on domain0, which >takes commands and runs them inside domainU and returns me the >results. > >The bottomline is a communication channel between dom0 and domU. Any ideas? > >Arijit > >_______________________________________________ >Xen-users mailing list >Xen-users@lists.xensource.com >http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I think I will go with the idea of having a private network. I have a xen-br1 bridge that is host-only. I created a domain that has its VIF connected to xen-br1. Now how do I make domain0 talk to domU. If we have support for tun/tap, I can create a virtual device in dom0 and make it one of the ports of the bridge. Seems like my xen-2.0.5 kernel doesn''t have tun modules. Any other way to establish such network based communication? Arijit On 9/1/05, Arijit Ganguly <aganguly@gmail.com> wrote:> By shared directory, do you mean an NFS share? > > Arijit > > On 9/1/05, Ernst Bachmann <e.bachmann@xebec.de> wrote: > > On Thursday 01 September 2005 22:11, Arijit Ganguly wrote: > > > All, > > > Is there any way we can set up a communication channel (not a TCP/IP > > > based network) between domain0 and unprivileged domains. This can be > > > useful in a way that we can write automatic configuration mechanisms > > > for our unprivileged VMs. > > > > From what I heard, XenFS will allow that kind of communication, for it > will > > be > > possibe to mmap a file from it in different domains and have shared memory > > > between domains that way. > > But thats still far from "running commands" in a target domain, so you''ll > > > still need some application to do that for you... > > Easiest solution for your problem would be probably a shared directory > with > > > > dom0 putting shellscripts or executables into, and domU polling that > > directory, executing and deleting whatever it finds... > > > > But it''ll be some time till XenFS will be available... > > > > > Illustration: > > > I have a domainU running on a host, which doesn;t have network > > > connectivity (like ssh). I just use the VM as a environment I can > > > issue commands and get results. Ports on domain0 are blocked > > > preventing me from accessing the VM console. I do not have an account > > > in domain0 for security. > > > What can be done is running a truested software on domain0, which > > > takes commands and runs them inside domainU and returns me the > > > results. > > > > > > The bottomline is a communication channel between dom0 and domU. Any > > ideas? > > > > Well, if its just that you want to "jail" suspicious software started from > > > dom0 in a domU: > > - mount the domU FS in dom0. > > - put your app in it, say /bin/something > > - unmount domU root > > - patch "init=/bin/something" into your domU config file as kernel param > > - xm start domU > > - wait till timeout or shutdown of domU, xm stop it > > - mount domU Root FS > > - read results... > > - maybe use a modified startscript or an entry in inittab instead of the > > "init=..." kernel param. > > > > > > If you just want to exchange some configuration data on domU, put it onto > > > domU''s kernel commandline, and read it back from /proc/cmdline inside > domU > > > > But I''d still say that a private bridge between domU and dom0 (not > connected > > > > to any real network device) and running ssh on it would be a more sensible > > > method. Without routing and maybe some ebtables scripts on it, that bridge > > > would be quite secure.I think I will go with the idea of having a private network. I have a xen-br1 bridge that is host-only. I created a domain that has its VIF connected to xen-br1. Now how do I make domain0 talk to domU.> > > > Did you have a look at the vserver kernel patches and tools > > (http://linux-vserver.org/)? Those might be by far better suited for your > > > problem. > > > > HTH > > /Ernst > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Marcus Brown
2005-Sep-03 00:20 UTC
Re: [Xen-users] Re: communication between dom0 and domu
Hi Arijit, Perhaps instead of a tun/tap device, try attaching a dummy to the bridge in dom0. You can even use multiple dummies if required with #modprobe -o dummy1 Marcus. Arijit Ganguly wrote:> I think I will go with the idea of having a private network. > > I have a xen-br1 bridge that is host-only. I created a domain that has > its VIF connected to xen-br1. Now how do I make domain0 talk to domU. > If we have support for tun/tap, I can create a virtual device in dom0 > and make it one of the ports of the bridge. Seems like my xen-2.0.5 > kernel doesn''t have tun modules. > > Any other way to establish such network based communication? > > Arijit > > > On 9/1/05, Arijit Ganguly <aganguly@gmail.com> wrote: > >>By shared directory, do you mean an NFS share? >> >>Arijit >> >>On 9/1/05, Ernst Bachmann <e.bachmann@xebec.de> wrote: >> >>>On Thursday 01 September 2005 22:11, Arijit Ganguly wrote: >>> >>>>All, >>>>Is there any way we can set up a communication channel (not a TCP/IP >>>>based network) between domain0 and unprivileged domains. This can be >>>>useful in a way that we can write automatic configuration mechanisms >>>>for our unprivileged VMs. >>> >>>From what I heard, XenFS will allow that kind of communication, for it >> >>will >> >>>be >>>possibe to mmap a file from it in different domains and have shared memory >> >>>between domains that way. >>>But thats still far from "running commands" in a target domain, so you''ll >> >>>still need some application to do that for you... >>>Easiest solution for your problem would be probably a shared directory >> >>with >> >>>dom0 putting shellscripts or executables into, and domU polling that >>>directory, executing and deleting whatever it finds... >>> >>>But it''ll be some time till XenFS will be available... >>> >>> >>>>Illustration: >>>>I have a domainU running on a host, which doesn;t have network >>>>connectivity (like ssh). I just use the VM as a environment I can >>>>issue commands and get results. Ports on domain0 are blocked >>>>preventing me from accessing the VM console. I do not have an account >>>>in domain0 for security. >>>>What can be done is running a truested software on domain0, which >>>>takes commands and runs them inside domainU and returns me the >>>>results. >>>> >>>>The bottomline is a communication channel between dom0 and domU. Any >>> >>>ideas? >>> >>>Well, if its just that you want to "jail" suspicious software started from >> >>>dom0 in a domU: >>>- mount the domU FS in dom0. >>>- put your app in it, say /bin/something >>>- unmount domU root >>>- patch "init=/bin/something" into your domU config file as kernel param >>>- xm start domU >>>- wait till timeout or shutdown of domU, xm stop it >>>- mount domU Root FS >>>- read results... >>>- maybe use a modified startscript or an entry in inittab instead of the >>>"init=..." kernel param. >>> >>> >>>If you just want to exchange some configuration data on domU, put it onto >> >>>domU''s kernel commandline, and read it back from /proc/cmdline inside >> >>domU >> >>>But I''d still say that a private bridge between domU and dom0 (not >> >>connected >> >>>to any real network device) and running ssh on it would be a more sensible >> >>>method. Without routing and maybe some ebtables scripts on it, that bridge >> >>>would be quite secure. > > I think I will go with the idea of having a private network. > > I have a xen-br1 bridge that is host-only. I created a domain that has > its VIF connected to xen-br1. Now how do I make domain0 talk to domU. > > >>>Did you have a look at the vserver kernel patches and tools >>>(http://linux-vserver.org/)? Those might be by far better suited for your >> >>>problem. >>> >>>HTH >>>/Ernst >>>_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ernst Bachmann
2005-Sep-03 08:07 UTC
Re: [Xen-users] Re: communication between dom0 and domu
On Saturday 03 September 2005 02:20, Marcus Brown wrote:> Hi Arijit, > > Perhaps instead of a tun/tap device, try attaching a dummy to the > bridge in dom0. You can even use multiple dummies if required with > #modprobe -o dummy1 > > Marcus. >Why would you want a dummy device attached to the bridge in dom0? The bridge itself works as network device, so only attaching the domU''s vifs should be enough: # brctl addbr test # ifconfig test 192.168.77.77 # brctl show bridge name bridge id STP enabled interfaces test 8000.000000000000 no ## the "test" bridge has no interfaces attached. # ifconfig test test Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.77.77 Bcast:192.168.77.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ## but it has an IP Address just fine. # ping 192.168.77.77 PING 192.168.77.77 (192.168.77.77) 56(84) bytes of data. 64 bytes from 192.168.77.77: icmp_seq=1 ttl=64 time=0.079 ms 64 bytes from 192.168.77.77: icmp_seq=2 ttl=64 time=0.039 ms --- 192.168.77.77 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.039/0.059/0.079/0.020 ms ## which works like a charm So, where would you need a tun/tap or dummy device? Usually, also the real eth devices bound to bridges in dom0 shouldn''t be configured with IP addresses, and the hosts ip-addr should be set on the bridge device only. The xen network scripts don''t remove the IP on eth0 when they create a bridge, tho, so thats what might''ve confused you. Hope that cleared things a bit, /Ernst _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Is there any way we can set up a communication channel (not a TCP/IP > based network) between domain0 and unprivileged domains. This can be > useful in a way that we can write automatic configuration mechanisms > for our unprivileged VMs. > > Illustration: > I have a domainU running on a host, which doesn;t have network > connectivity (like ssh). I just use the VM as a environment I can > issue commands and get results. Ports on domain0 are blocked > preventing me from accessing the VM console. I do not have an account > in domain0 for security. > What can be done is running a truested software on domain0, which > takes commands and runs them inside domainU and returns me the > results.I guess one solution would be to have a console server in dom0 that uses something like SSL to enable secure, authenticated access to the domain console. I think this is on the cards but not implemented yet... The other guys solutions may help you in the meantime. Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> On Thursday 01 September 2005 22:11, Arijit Ganguly wrote: > > All, > > Is there any way we can set up a communication channel (not a TCP/IP > > based network) between domain0 and unprivileged domains. This can be > > useful in a way that we can write automatic configuration mechanisms > > for our unprivileged VMs. > > From what I heard, XenFS will allow that kind of communication, for it will > be possibe to mmap a file from it in different domains and have shared > memory between domains that way. > But thats still far from "running commands" in a target domain, so you''ll > still need some application to do that for you... > Easiest solution for your problem would be probably a shared directory with > dom0 putting shellscripts or executables into, and domU polling that > directory, executing and deleting whatever it finds... > > But it''ll be some time till XenFS will be available...Didn''t notice the mention earlier :-) XenFS should be handy for interdomain communications but it''ll be better suited to high-speed / low overhead transfers using shared memory. I think that in this case what Arijit wants can be solved most easily by some solution involving a secure interface the console (as you guys have been talking about elsewhere in this thread). Cheers, Mark> > Illustration: > > I have a domainU running on a host, which doesn;t have network > > connectivity (like ssh). I just use the VM as a environment I can > > issue commands and get results. Ports on domain0 are blocked > > preventing me from accessing the VM console. I do not have an account > > in domain0 for security. > > What can be done is running a truested software on domain0, which > > takes commands and runs them inside domainU and returns me the > > results. > > > > The bottomline is a communication channel between dom0 and domU. Any > > ideas? > > Well, if its just that you want to "jail" suspicious software started from > dom0 in a domU: > - mount the domU FS in dom0. > - put your app in it, say /bin/something > - unmount domU root > - patch "init=/bin/something" into your domU config file as kernel param > - xm start domU > - wait till timeout or shutdown of domU, xm stop it > - mount domU Root FS > - read results... > - maybe use a modified startscript or an entry in inittab instead of the > "init=..." kernel param. > > > If you just want to exchange some configuration data on domU, put it onto > domU''s kernel commandline, and read it back from /proc/cmdline inside domU > > But I''d still say that a private bridge between domU and dom0 (not > connected to any real network device) and running ssh on it would be a more > sensible method. Without routing and maybe some ebtables scripts on it, > that bridge would be quite secure. > > Did you have a look at the vserver kernel patches and tools > (http://linux-vserver.org/)? Those might be by far better suited for your > problem. > > HTH > /Ernst > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users