hi, i notice that there''s a management interface on port 8000. i seek to protect this interface such that nothing but a trusted program (think selinux) may run, manage, start up or shut down xen oses. so: where can i find out information about the structure of the xen management interface? is the port 8000 stuff just providing a web server (/etc/init.d/xend) front-end to some extra system calls? is the port 8000 stuff actually running in the xen boot-up stuff? if it''s some extra system calls that''s very good because it will be possible to add selinux security hooks to protect each system call. ta, l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> -- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Right, xend is just an HTTP interface to Xen via system calls or ioctls (xend <--> linux <--> Xen). There''s also a daemon (xfrd) running on 8002. There currently is no authentication on either port. In the source tree, look at docs/misc/xend.tex, although some details are out of date. HTH, Charles>>>Luke Kenneth Casson Leighton <lkcl@lkcl.net> 11/23/04 10:05 am >>>hi, i notice that there''s a management interface on port 8000. i seek to protect this interface such that nothing but a trusted program (think selinux) may run, manage, start up or shut down xen oses. so: where can i find out information about the structure of the xen management interface? is the port 8000 stuff just providing a web server (/etc/init.d/xend) front-end to some extra system calls? is the port 8000 stuff actually running in the xen boot-up stuff? if it''s some extra system calls that''s very good because it will be possible to add selinux security hooks to protect each system call. ta, l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> -- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Charles Coffing wrote:> Right, xend is just an HTTP interface to Xen via system calls or ioctls > (xend <--> linux <--> Xen). > > There''s also a daemon (xfrd) running on 8002. > > There currently is no authentication on either port. > > In the source tree, look at docs/misc/xend.tex, although some details > are out of date. >Correct, though you can configure the interface listened to by xend in the xend config. The default is open. To disable network access configure ''localhost''. See ''xend-address'' in ''/etc/xen/xend-config.sxp''. Xend is implemented using the Twisted framework in Python, and this supports configuring https and authentication in front of web services - we just haven''t got around to it. There''s currently no security on port 8002 for the transfer daemon (xfrd). There are various things that could be done. For example xfrd could be set to listen on loopback only and you could use ssh or stunnel to secure the comms and forward ports. I''m hoping to get around to securing this.> > HTH, > Charles > > > >>>>Luke Kenneth Casson Leighton <lkcl@lkcl.net> 11/23/04 10:05 am >>> > > hi, > > i notice that there''s a management interface on port 8000. > > i seek to protect this interface such that nothing but a trusted program > > (think selinux) may run, manage, start up or shut down xen oses. > > so: where can i find out information about the structure of the > xen management interface? > > is the port 8000 stuff just providing a web server (/etc/init.d/xend) > front-end to some extra system calls? > > is the port 8000 stuff actually running in the xen boot-up stuff? > > if it''s some extra system calls that''s very good because it will be > possible to add selinux security hooks to protect each system call. > > ta, > > l. >Mike ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Luke Kenneth Casson Leighton wrote:> hi, > > i notice that there''s a management interface on port 8000. > > i seek to protect this interface such that nothing but a trusted program > (think selinux) may run, manage, start up or shut down xen oses. > > so: where can i find out information about the structure of the > xen management interface? > > is the port 8000 stuff just providing a web server (/etc/init.d/xend) > front-end to some extra system calls?What lives behind port 8000 is xend. This is the management daemon for xen. It presents its interface over HTTP and implements it using low-level calls into the xen hypervisor via ioctls. There is no system call interface that corresponds to the xend api.> > is the port 8000 stuff actually running in the xen boot-up stuff?Xen boots the hypervisor, then domain-0. Xend runs in domain-0 and is the normal way that all other domains get started.> if it''s some extra system calls that''s very good because it will be > possible to add selinux security hooks to protect each system call.You should be able to use selinux rules to specify what gets to talk to xend at port 8000. You''d need to enable LSM and selinux in the domain-0 kernel, but otherwise all you should need to do is configure selinux appropriately.> ta, > > l. >Hope this helps, Mike ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> i notice that there''s a management interface on port 8000.There are currently two HTTP-based management interfaces. Once of them is the Xensv web interface, the other is the Xend HTTP-based API, which is used by both the command line xm tool and Xensv to issue commands to Xend.> i seek to protect this interface such that nothing but a trusted program > (think selinux) may run, manage, start up or shut down xen oses.Currently, anyone who can access Xend''s port can issue management commands. Xend can optionally be configured to only accept connections from localhost, in which case only local users will be able to issue commands to it.> is the port 8000 stuff just providing a web server (/etc/init.d/xend) > front-end to some extra system calls?Not exactly. At the Linux Level, there aren''t any extra Xen system calls. Most commands are issued to Xen by performing ioctls on the /proc/xen/privcmd file. The commands which are issued through this file are largely transparent to XenLinux however, having meaning only when they are parsed by Xen.> is the port 8000 stuff actually running in the xen boot-up stuff?Xend starts its HTTP interface when it starts up and will do anything the HTTP interface tells it to do. If Xend isn''t running then the HTTP interface is not accessible (but you can''t do a lot without Xend). HTH, Mark> > ta, > > l. > > -- > -- > <a href="http://lkcl.net">http://lkcl.net</a> > -- > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel >------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Tue, Nov 23, 2004 at 06:07:52PM +0000, Mark Williamson wrote:> >i notice that there''s a management interface on port 8000. > > There are currently two HTTP-based management interfaces. Once of them is > the Xensv web interface, the other is the Xend HTTP-based API, which is > used by both the command line xm tool and Xensv to issue commands to Xend. > > >i seek to protect this interface such that nothing but a trusted program > >(think selinux) may run, manage, start up or shut down xen oses. > > Currently, anyone who can access Xend''s port can issue management > commands. Xend can optionally be configured to only accept connections > from localhost, in which case only local users will be able to issue > commands to it.okay. is there anything preventing that interface from being removed, such that the client/server bit is munged into a single application?> >is the port 8000 stuff just providing a web server (/etc/init.d/xend) > >front-end to some extra system calls? > > Not exactly. At the Linux Level, there aren''t any extra Xen system calls. > Most commands are issued to Xen by performing ioctls on the > /proc/xen/privcmd file.GREAT. that means that it will be possible to lock down at the very least the access to /proc/xen and later, should it prove worthwhile, to protect each ioctl with a new selinux security id per ioctl command.> The commands which are issued through this file > are largely transparent to XenLinux however, having meaning only when they > are parsed by Xen.... that kinda goes without saying :)> >is the port 8000 stuff actually running in the xen boot-up stuff? > > Xend starts its HTTP interface when it starts up and will do anything the > HTTP interface tells it to do. If Xend isn''t running then the HTTP > interface is not accessible (but you can''t do a lot without Xend).... but there''s nothing to prevent the merging of the xend and the xm programs, bypassing the use of HTTP, right? ta, l. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Tue, Nov 23, 2004 at 06:07:28PM +0000, Mike Wray wrote:> You should be able to use selinux rules to specify what gets to talk to > xend at port 8000. You''d need to enable LSM and selinux in the domain-0 > kernel, but > otherwise all you should need to do is configure selinux appropriately.yes it does: i was however thinking along the lines of creating selinux security IDs, one for each type of xen command (create, list, shutdown, start, stop etc.) and then writing an selinux policy granting xm the right to perform those commands. ... if the xm and xend programs cannot be merged for some reason, there isn''t any point in taking that approach. l. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > >is the port 8000 stuff actually running in the xen boot-up stuff? > > > > Xend starts its HTTP interface when it starts up and will do anything the > > HTTP interface tells it to do. If Xend isn''t running then the HTTP > > interface is not accessible (but you can''t do a lot without Xend). > > ... but there''s nothing to prevent the merging of the xend and the xm > programs, bypassing the use of HTTP, right?You might want to think twice before doing that, or at least have some alternative story about how you''d do administration of a pool of VMs running over a cluster of nodes. I guess you''re probably thinking of multi-level secure VMs on a single host (e.g. a laptop), but the cluster side is important too. I guess it might be possible to weld xm and xend directly to each other in the single machine case. Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Tue, Nov 23, 2004 at 09:03:39PM +0000, Ian Pratt wrote:> > > >is the port 8000 stuff actually running in the xen boot-up stuff? > > > > > > Xend starts its HTTP interface when it starts up and will do anything the > > > HTTP interface tells it to do. If Xend isn''t running then the HTTP > > > interface is not accessible (but you can''t do a lot without Xend). > > > > ... but there''s nothing to prevent the merging of the xend and the xm > > programs, bypassing the use of HTTP, right? > > You might want to think twice before doing that, or at least have > some alternative story about how you''d do administration of a > pool of VMs running over a cluster of nodes. > > I guess you''re probably thinking of multi-level secure VMs on a > single host (e.g. a laptop),yes (see below for details).> but the cluster side is important > too.ah, so. even inside a guest OS is it possible to access the HTTP interface?> I guess it might be possible to weld xm and xend directly to each > other in the single machine case.perhaps i should explain: i am looking to use xen to implement a new level of paranoid security. i aim to run single applications, such as firefox and openoffice, in their own dedicated virtual machines, a localised file server in one (or more if i can get GFS or OCFS2 to work) virtual machine(s), and for the applications to each connect to the xen master running an x-server [nomachine isn''t quite suitable, i may have to write my own ssh-based x-proxy]. allowing a compromised guest OS to fire up another virtual machine, connect to the x-server and spoof "please enter your password" dialog boxes is therefore to be avoided!!! i am so pleased and relieved that xm is written in python. i grok python. l. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Luke Kenneth Casson Leighton wrote:> > perhaps i should explain: i am looking to use xen to implement > a new level of paranoid security. > > i aim to run single applications, such as firefox and > openoffice, in their own dedicated virtual machines, a > localised file server in one (or more if i can get GFS or OCFS2 > to work) virtual machine(s), and for the applications to each > connect to the xen master running an x-server [nomachine isn''t > quite suitable, i may have to write my own ssh-based x-proxy].Do you mean running xserver in domain0? You should better setup separate domain for it. But are you sure that such a setup will be usable and fast enough? I''m definitely interested in results, anyway.> allowing a compromised guest OS to fire up another virtual > machine, connect to the x-server and spoof "please enter your > password" dialog boxes is therefore to be avoided!!!If I''m not mistaken, you can start up new VMs only from domain0 or through HTTP interface, So you can easily firewall all traffic inside domain0 to local port 8000 (except for 127.0.0.1/32). j. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> is there anything preventing that interface from being removed, such > that the client/server bit is munged into a single application?In older releases, there wasn''t a Xend. Instead we had a set of management scripts that called various operations directly. You could in principle munge xm and xend together into a big megatool but it wouldn''t be pretty. Xend makes concurrency control much easier, provides a central point of contact regarding machine state and demuxes the virtual consoles of the domain. You''d have to address these problems in addition to combining the tools, which would take a fair bit of hacking to do properly.>> Not exactly. At the Linux Level, there aren''t any extra Xen system calls. >> Most commands are issued to Xen by performing ioctls on the >> /proc/xen/privcmd file. > > GREAT. > > that means that it will be possible to lock down at the very least the > access to /proc/xen and later, should it prove worthwhile, to protect > each ioctl with a new selinux security id per ioctl command.Right now, only root (actually, probably users with the CAP_SYSADMIN capability or similar) can do operations on /proc/xen. Also, many Xen operations are mapped onto one ioctl call so as it is you can''t do very fine grained protection based on ioctl number. What you describe would be technically possible if a separate ioctl was allocated for each operation, though. Cheers, Mark ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> -----Original Message----- > From: xen-devel-admin@lists.sourceforge.net [mailto:xen-devel- > admin@lists.sourceforge.net] On Behalf Of Mark Williamson > Sent: 23 November 2004 22:49 > To: Luke Kenneth Casson Leighton > Cc: xen-devel@lists.sourceforge.net > Subject: Re: [Xen-devel] protecting xen startup > > > is there anything preventing that interface from being removed, such > > that the client/server bit is munged into a single application? > > In older releases, there wasn''t a Xend. Instead we had a set of > management scripts that called various operations directly. You couldin> principle munge xm and xend together into a big megatool but itwouldn''t> be pretty.Well not quite since in the older releases we also didn''t have event channels and control channels. Basically with the new IO model we need something somewhere which either connects event channels or which at least assists two domains to set up a event channel with shared memory pages (ie a name server).>From a security point of view we probably should/need to restructure thecurrent xend significantly into at least two components: a small name server and a daemon/tool which knows about assignment of higher level devices to domains etc. Note that this will also require changes to backend and frontends etc, ie, it''s non-trivial.> Xend makes concurrency control much easier, provides a central pointof> contact regarding machine state and demuxes the virtual consoles ofthe> domain. You''d have to address these problems in addition to combiningthe> tools, which would take a fair bit of hacking to do properly. > > >> Not exactly. At the Linux Level, there aren''t any extra Xen system > calls. > >> Most commands are issued to Xen by performing ioctls on the > >> /proc/xen/privcmd file. > > > > GREAT. > > > > that means that it will be possible to lock down at the very leastthe> > access to /proc/xen and later, should it prove worthwhile, toprotect> > each ioctl with a new selinux security id per ioctl command. > > Right now, only root (actually, probably users with the CAP_SYSADMIN > capability or similar) can do operations on /proc/xen. Also, many Xen > operations are mapped onto one ioctl call so as it is you can''t dovery> fine grained protection based on ioctl number. What you describewould be> technically possible if a separate ioctl was allocated for eachoperation,> though.In general, as ian pointed out, the current design is more geared towards clusters, however, we started looking into security applications of Xen and will hopefully address these issues in future releases. Currently, our thinking is also very much along the lines of leveraging SELinux as much as possible at least for the first prototype, however there are several changes we would have to make first ... rolf> Cheers, > Mark > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from realusers.> Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Tue, Nov 23, 2004 at 10:49:24PM +0000, Mark Williamson wrote:> >is there anything preventing that interface from being removed, such > >that the client/server bit is munged into a single application? > > In older releases, there wasn''t a Xend. Instead we had a set of > management scripts that called various operations directly. You could in > principle munge xm and xend together into a big megatool but it wouldn''t > be pretty.i''ll take that as a challenge, then :)> Xend makes concurrency control much easier, provides a central point of > contact regarding machine state and demuxes the virtual consoles of the > domain. You''d have to address these problems in addition to combining the > tools, which would take a fair bit of hacking to do properly.okay. assuming that 1) i don''t want a central point of contact i only want _one_ point of contact and 2) i can live without virtual consoles until i understand the code enough and can get away with using ssh logins instead: would this be a simple enough task for someone not entirely familiar with xen''s code [but who has developed a number of 20k+ line python projects over the past four years]?> >>Not exactly. At the Linux Level, there aren''t any extra Xen system calls. > >>Most commands are issued to Xen by performing ioctls on the > >>/proc/xen/privcmd file. > > > >GREAT. > > > >that means that it will be possible to lock down at the very least the > >access to /proc/xen and later, should it prove worthwhile, to protect > >each ioctl with a new selinux security id per ioctl command. > > Right now, only root (actually, probably users with the CAP_SYSADMIN > capability or similar) can do operations on /proc/xen.[which, please excuse me for saying so, doesn''t exactly help if that root-only interface is then exposed via an open high port number!! :) ]> Also, many Xen > operations are mapped onto one ioctl call so as it is you can''t do very > fine grained protection based on ioctl number.i was thinking of adding in an LSM hook function that received the ioctl number as one of its arguments, translated that in a case statement into the corresponding selinux SIDs, and from there checked an selinux permission - in a similar way that security/selinux/hooks.c''s selinux_file_ioctl() or the selinux_file_fcntl() function operates. i.e. not using file_has_perm() but task_has_perm() instead. then the first thing that the xen ioctl function does is call that LSM hook function. it would therefore also be possible for someone else to write a corresponding LSM linux capabilities function call, too. should someone so wish. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> -- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Tue, Nov 23, 2004 at 11:00:57PM +0100, Jan Kundr?t wrote:> Luke Kenneth Casson Leighton wrote: > > > > perhaps i should explain: i am looking to use xen to implement > > a new level of paranoid security. > > > > i aim to run single applications, such as firefox and > > openoffice, in their own dedicated virtual machines, a > > localised file server in one (or more if i can get GFS or OCFS2 > > to work) virtual machine(s), and for the applications to each > > connect to the xen master running an x-server [nomachine isn''t > > quite suitable, i may have to write my own ssh-based x-proxy]. > > Do you mean running xserver in domain0?um, yes.> You should better setup separate > domain for it.really? is that possible? can i run an xserver in a separate guest OS and still allow the guest OS direct access to the screen? how is that done - via a framebuffer drive? tellmetellme!!!!> But are you sure that such a setup will be usable and fast enough?i gonna find out :)> > allowing a compromised guest OS to fire up another virtual > > machine, connect to the x-server and spoof "please enter your > > password" dialog boxes is therefore to be avoided!!! > > If I''m not mistaken, you can start up new VMs only from domain0 or > through HTTP interface, So you can easily firewall all traffic inside > domain0 to local port 8000 (except for 127.0.0.1/32).yeh, *grumble*, and you can also, in selinux, ban applications from accessing a port.> j. >-- -- <a href="http://lkcl.net">http://lkcl.net</a> -- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> can i run an xserver in a separate guest OS and still allow the guest > OS direct access to the screen? > > how is that done - via a framebuffer drive? > > tellmetellme!!!!There was a very brave chap who had a second PCI graphics card and a second PCI USB controller, which he had given a domain (!=dom0) privileges to access and was trying to persuade X to run. I''m not sure how far he''s got now but it''s not straightforward.>> If I''m not mistaken, you can start up new VMs only from domain0 or >> through HTTP interface, So you can easily firewall all traffic inside >> domain0 to local port 8000 (except for 127.0.0.1/32). > > yeh, *grumble*, and you can also, in selinux, ban applications from > accessing a port.Well by setting Xend to only receive connections from localhost and then applying SELinux, you can at least restrict access to the control interface to root... Cheers, Mark ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
>> Xend makes concurrency control much easier, provides a central point of >> contact regarding machine state and demuxes the virtual consoles of the >> domain. You''d have to address these problems in addition to combining the >> tools, which would take a fair bit of hacking to do properly. > > okay. > > assuming that 1) i don''t want a central point of contact i only want > _one_ point of contact and 2) i can live without virtual consoles > until i understand the code enough and can get away with > using ssh logins instead: > > would this be a simple enough task for someone not entirely > familiar with xen''s code [but who has developed a number of > 20k+ line python projects over the past four years]?You''d need to be fairly familiar with Xen, particularly the virtual device channels. There''s a general purpose transport for control messages between domain0 and other domains. Multiple messages are sent to and from Xend in order to set up every virtual device. You can''t do without these, so you''d have to find some way of doing this. As Rolf said, you do still need a central point of contact in the system for some operations, in order to ensure safety. The main reason for this (imo) is to prevent concurrent accesses to domain0''s control interface. You could have a daemon to take care of this or write a Linux device driver to access the control interface for you. HTH, Mark ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, Nov 24, 2004 at 08:17:27AM +0000, Mark Williamson wrote:> >can i run an xserver in a separate guest OS and still allow the guest > >OS direct access to the screen? > > > >how is that done - via a framebuffer drive? > > > >tellmetellme!!!! > > There was a very brave chap who had a second PCI graphics card and a > second PCI USB controller, which he had given a domain (!=dom0) privileges > to access and was trying to persuade X to run. I''m not sure how far he''s > got now but it''s not straightforward.that''s what i kinda figured: that the solution would open up a larger can of worms than the alternative. not that i''m happy with it but it appears to be the simplest solution. _another_ alternative which i don''t believe offers _that_ much benefit is to run nomachine: /etc/apt/sources.list -> deb http://debian.tu-bs.de/knoppix/nx/slh-debian/ ./ then it''d be possible to turn the xen master domain into a thin client and have kde / gnome / fvwm / whatever running in a guest domain. ... but nomachine is quirky to set up, even with the packages being available at the above location. l. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Tue, Nov 23, 2004 at 11:58:51PM -0000, Neugebauer, Rolf wrote:> From a security point of view we probably should/need to restructure the > current xend significantly into at least two components: a small name > server and a daemon/tool which knows about assignment of higher level > devices to domains etc. Note that this will also require changes to > backend and frontends etc, ie, it''s non-trivial.hi rolf, i''m not familiar enough with the terminology that you are using to understand fully what you are saying. are you hinting at the allocation of device drivers across domains? e.g. having one domain do the hardware side and securely proxy-forwarding the access to that device over to another domain? for example /dev/console in one domain being proxy-forwarded into another domain for it to be accessible as /dev/xendomainconsole0, something like that? because if so that _would_ be great because it''d be a trivial job in selinux to set up an selinux permission to access the device inode at the "receiving" end so to speak. ... but i have to point out that i''m more concerned about leveraging what is available - right now - than i am about future versions. l. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> -----Original Message----- > From: Luke Kenneth Casson Leighton [mailto:lkcl@lkcl.net] > Sent: 24 November 2004 10:53 > To: Neugebauer, Rolf > Cc: Mark Williamson; xen-devel@lists.sourceforge.net > Subject: Re: [Xen-devel] protecting xen startup > > On Tue, Nov 23, 2004 at 11:58:51PM -0000, Neugebauer, Rolf wrote: > > > From a security point of view we probably should/need to restructurethe> > current xend significantly into at least two components: a smallname> > server and a daemon/tool which knows about assignment of higherlevel> > devices to domains etc. Note that this will also require changes to > > backend and frontends etc, ie, it''s non-trivial. > > hi rolf, > > i''m not familiar enough with the terminology that you are using to > understand fully what you are saying. > > are you hinting at the allocation of device drivers across domains? > > e.g. having one domain do the hardware side and securely > proxy-forwarding the access to that device over to another domain?We run native device drivers in a privileged VM and and in order to share physical devices amongst VMs this VM then exports these to other VMs via idealized/virtual interfaces. The VM with the native device driver exports devices via a backend driver and the VMs using a virtual device run a small stub frontend device driver. The communication between BE and FW is done via shared memory pages and access to these is synchronized via event channels.> for example /dev/console in one domain being proxy-forwarded into > another domain for it to be accessible as /dev/xendomainconsole0, > something like that? > > because if so that _would_ be great because it''d be a trivial job in > selinux to set up an selinux permission to access the device inode > at the "receiving" end so to speak.Yes, in principle you should be able to do that (and we have been thinking along similar lines). However, at the moment the linux kernel in the exporting VM (BE) does not know anything about other VMs so as far as my understanding goes you can''t apply SELinux policies to it as you don''t have a subject. Rolf> > ... but i have to point out that i''m more concerned about leveraging > what is available - right now - than i am about future versions. > > l.------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> are you hinting at the allocation of device drivers across domains? > > e.g. having one domain do the hardware side and securely > proxy-forwarding the access to that device over to another domain?Well, this is really already done. e.g. net and block devices are securely shared. Domain 0 runs the real physical device driver and the unprivileged domain uses a virtual device driver to communicate its requests to dom0. These are requests are validated before being accepted. Setting up these "device channels" is reasonably involved. A protocol using the control message framework is used to communicate to the "backend" (runs in dom0 and co-ordinates sharing) and "frontend" (runs in guest and provides virtual devices to the guest) about what virtual devices exist. The protocol is then used to establish a shared-memory connection between the two. One problem here is that domain 0''s control interface (used to communicate with the backend drivers) can only have one writer. Hence it''s necessary to ensure mutual exclusion - we let Xend control writing requests to this interface. As well as keeping track of various forms of state, you also need to ensure that the control interface is dealt with correctly, which could be quite a bit of work.> ... but i have to point out that i''m more concerned about leveraging > what is available - right now - than i am about future versions.Sure thing. We''re planning to add mandatory access control features at some stage but that''s still on the drawing board at the moment. In the meantime, there should be plenty of other fun to be had... Cheers, Mark ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, Nov 24, 2004 at 11:48:15AM -0000, Neugebauer, Rolf wrote:> Yes, in principle you should be able to do that (and we have been > thinking along similar lines). However, at the moment the linux kernel > in the exporting VM (BE) does not know anything about other VMs so as > far as my understanding goes you can''t apply SELinux policies to it as > you don''t have a subject.okay. that can be dealt with by... (this is speculation, here!) by writing an selinux policy in advance that defines how many virtual machines you have, and creating xen_vm0_t, xen_vm1_t etc. to represent them. you then define what operations can be carried out, and then grant a program the right to perform that operation on SPECIFIC machines. [yes there is a short-hand which allows you to specify an operation be allowed by a program on all machines]. then it would be necessary to modify the linux kernel to call the avc_has_perm() function at the appropriate point to check, at the time that an operation was being done (e.g. read from block device), as to whether that process had the right to perform that operation on that xen virtual machine. in order for this to work, it would be necessary to have a translation mechanism between the numbering xen_vm_0_t etc. and the actual xen virtual machines. looking at avc_has_perm(), you''d need a SID per virtual machine, as the second argument... xen_communication_has_perm(struct task_struct *tsk, struct xen_info *xen, u32 perms) { return avc_has_perm(tsec->sid, xen->sid, SECCLASS_XEN, perms, NULL, NULL); } where xen->sid contains "xen_vm_0_t", "xen_vm_1_t" etc. and tsec->sid contains "xen_xm_bin_t" - representing the xen control binary /usr/bin/xm. the question i can''t answer (the bit that i don''t quite grok) is how do you get hold of the right xen_info struct and how do you blat the sid into it? l. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, Nov 24, 2004 at 03:24:02PM +0000, Luke Kenneth Casson Leighton wrote:> where xen->sid contains "xen_vm_0_t", "xen_vm_1_t" etc. > and tsec->sid contains "xen_xm_bin_t" - representing the xen control > binary /usr/bin/xm. > > the question i can''t answer (the bit that i don''t quite grok) is > how do you get hold of the right xen_info struct and how do you blat > the sid into it?sorry to be replying to my own message with another question, but would it be reasonable to have a function which adds some state info into the VM? what i mean by that is, would it be reasonable to add some functions xen_get_selinux_sid and xen_set_selinux_sid which are effectively the same as ext2/3 get and set xattrs "security.selinux"? such that it would be possible, on creation of a new xen guest session, to associate a SID with that session (e.g. "xen_vm_0_t") and then to be able to retrieve it again in the ioctls? l. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel