protecting xen startup

protecting xen startup

[Luke Kenneth Casson Leighton]

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/

Re: protecting xen startup

[Mike Wray]

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/

Re: protecting xen startup

[Luke Kenneth Casson Leighton]

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/

Re: protecting xen startup

[Mark Williamson]

> 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/

Re: protecting xen startup

[Luke Kenneth Casson Leighton]

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/

Re: protecting xen startup

[Ian Pratt]

> > >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/

Re: protecting xen startup

[Luke Kenneth Casson Leighton]

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/

Re: protecting xen startup

[Jan Kundrát]

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/

Re: protecting xen startup

[Luke Kenneth Casson Leighton]

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/

Re: protecting xen startup

[Mark Williamson]

> 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/

Re: protecting xen startup

[Luke Kenneth Casson Leighton]

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/

Re: protecting xen startup

[Mark Williamson]

> 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/

Re: [Xen-devel] protecting xen startup

[Luke Kenneth Casson Leighton]

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>
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: protecting xen startup

[Luke Kenneth Casson Leighton]

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/

Re: protecting xen startup

[Mark Williamson]

>> 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/

Re: protecting xen startup

[Charles Coffing]

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/

Re: protecting xen startup

[Mike Wray]

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/

RE: protecting xen startup

[Neugebauer, Rolf]

> -----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 could
in
> principle munge xm and xend together into a big megatool but it
wouldn'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 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.

> 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.

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 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/

Re: protecting xen startup

[Luke Kenneth Casson Leighton]

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/

Re: protecting xen startup

[Mark Williamson]

> 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/

RE: protecting xen startup

[Neugebauer, Rolf]

> -----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 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?

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/

Re: protecting xen startup

[Luke Kenneth Casson Leighton]

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/

Re: protecting xen startup

[Luke Kenneth Casson Leighton]

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/