[PATCH] xen-2.0: privileged port connections

[PATCH] xen-2.0: privileged port connections

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 935 bytes --]

Hi,

as discussed previously, I went ahead and introduced a setting that
allows you to restrict the stuff you can when controlling xen by
connecting to the port 8000 unless you connect from a privileged
port.

I did not yet bother to look at the event port nor did I try to address
the consoles. The consoles will be done in a second patch if this 
approach is deemed appropriate. 

Note that I also do still allow unprivileged connections still to gather
most of the information. This can be debated, but I'm not such a big fan
of security by obscurity.

I hope I did not miss anything important for the control stuff.

The patch also fixes one typo (missing ") in SrvNode.py.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>             [Koeln, DE]
Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL]
Linux: SUSE Labs (Director)    <garloff@suse.de>            [Novell Inc]

[-- Attachment #1.2: xen-secure.diff --]
[-- Type: text/plain, Size: 13610 bytes --]

Signed-off-by: Kurt Garloff <garloff@suse.de>

diff -uNrp xen-2.0-testing/tools/examples/xend-config.sxp xen-2.0-testing.secure/tools/examples/xend-config.sxp
--- xen-2.0-testing/tools/examples/xend-config.sxp	2005-03-21 04:58:08.000000000 +0100
+++ xen-2.0-testing.secure/tools/examples/xend-config.sxp	2005-03-23 13:18:01.167841981 +0100
@@ -11,6 +11,15 @@
 # Specifying the empty string '' allows all connections.
 (xend-address      'localhost')
 
+# Set this to 1 to restrict the access to the xend port
+# to connections from a privileged port (<1024); together
+# with binding to localhost, this will restrict xen control
+# to the root user in domain0.
+# Note that the protection is not yet complete, consoles
+# are not yet protected. Also, most read-only information
+# ist still readable.
+(xend-privileged-port   1)
+
 # The port xend should start from when allocating a port
 # for a domain console.
 (console-port-base 9600)
diff -uNrp xen-2.0-testing/tools/python/xen/xend/XendProtocol.py xen-2.0-testing.secure/tools/python/xen/xend/XendProtocol.py
--- xen-2.0-testing/tools/python/xen/xend/XendProtocol.py	2005-03-21 04:58:03.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/XendProtocol.py	2005-03-23 13:13:25.686990578 +0100
@@ -1,6 +1,7 @@
 # Copyright (C) 2004 Mike Wray <mike.wray@hp.com>
 
 import httplib
+import socket
 import types
 
 from encode import *
@@ -122,6 +123,43 @@ class XendClientProtocol:
         """
         raise NotImplementedError()
 
+class xenhttpconn(httplib.HTTPConnection):
+    """A httplib class with slightly modified connect function that
+    tries to grab a privileged source port.
+    """
+
+    def connect(self):
+        """Connect to the host and port specified in __init__."""
+        msg = "getaddrinfo returns an empty list"
+        for res in socket.getaddrinfo(self.host, self.port, 0,
+                                      socket.SOCK_STREAM):
+            af, socktype, proto, canonname, sa = res
+            try:
+                self.sock = socket.socket(af, socktype, proto)
+                if self.debuglevel > 0:
+                    print "connect: (%s, %s)" % (self.host, self.port)
+                # Try to get a src port below 1024
+                port = 732
+                while port < 1024:
+                    try:
+                        self.sock.bind(("", port))
+                    except socket.error, msg:
+			port += 1
+                    else:
+                        break
+                self.sock.connect(sa)
+            except socket.error, msg:
+                if self.debuglevel > 0:
+                    print 'connect fail:', (self.host, self.port)
+                if self.sock:
+                    self.sock.close()
+                self.sock = None
+                continue
+            break
+        if not self.sock:
+            raise socket.error, msg
+
+
 class SynchXendClientProtocol(XendClientProtocol):
     """A synchronous xend client. This will make a request, wait for
     the reply and return the result.
@@ -137,7 +175,7 @@ class SynchXendClientProtocol(XendClient
         @param args:   request arguments (dict)
         """
         self.request = XendRequest(url, method, args)
-        conn = httplib.HTTPConnection(url.location())
+        conn = xenhttpconn(url.location())
         if DEBUG: conn.set_debuglevel(1)
         conn.request(method, url.fullpath(), self.request.data, self.request.headers)
         resp = conn.getresponse()
diff -uNrp xen-2.0-testing/tools/python/xen/xend/XendRoot.py xen-2.0-testing.secure/tools/python/xen/xend/XendRoot.py
--- xen-2.0-testing/tools/python/xen/xend/XendRoot.py	2005-03-21 04:58:04.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/XendRoot.py	2005-03-23 13:18:56.085242803 +0100
@@ -47,6 +47,9 @@ class XendRoot:
     """Default interface address xend listens at. """
     xend_address_default      = ''
 
+    """Default for xend-privileged """
+    xend_privileged_port_default   = 1
+
     """Default port xend serves HTTP at. """
     xend_port_default         = '8000'
 
@@ -236,6 +239,12 @@ class XendRoot:
         """
         return self.get_config_value('xend-address', self.xend_address_default)
 
+    def get_xend_privileged_port(self):
+	"""Get the setting that controls whether xend only accepts connections
+	from privileged ports.
+	"""
+	return self.get_config_value('xend-privileged-port', self.xend_privileged_port_default)
+
     def get_console_address(self):
         """Get the address xend listens at for its console ports.
         This defaults to the empty string which allows all hosts to connect.
diff -uNrp xen-2.0-testing/tools/python/xen/xend/server/SrvConsole.py xen-2.0-testing.secure/tools/python/xen/xend/server/SrvConsole.py
--- xen-2.0-testing/tools/python/xen/xend/server/SrvConsole.py	2005-03-21 04:58:07.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/server/SrvConsole.py	2005-03-23 13:13:25.634999664 +0100
@@ -17,9 +17,6 @@ class SrvConsole(SrvDir):
         val = self.xc.console_disconnect(self.info.console_port)
         return val
 
-    def render_POST(self, req):
-        return self.perform(req)
-        
     def render_GET(self, req):
         try:
             if self.use_sxp(req):
@@ -32,7 +29,8 @@ class SrvConsole(SrvDir):
                 req.write('<p>%s</p>' % self.info)
                 req.write('<p><a href="%s">Connect to domain %d</a></p>'
                           % (self.info.uri(), self.info.dom))
-                self.form(req)
+		if self.isAuthorized(req):
+		    self.form(req)
                 req.write('</body></html>')
             return ''
         except Exception, ex:
diff -uNrp xen-2.0-testing/tools/python/xen/xend/server/SrvDir.py xen-2.0-testing.secure/tools/python/xen/xend/server/SrvDir.py
--- xen-2.0-testing/tools/python/xen/xend/server/SrvDir.py	2005-03-21 04:58:04.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/server/SrvDir.py	2005-03-23 13:19:35.073427804 +0100
@@ -8,6 +8,9 @@ from xen.xend.XendError import XendError
 
 from SrvBase import SrvBase
 
+from xen.xend import XendRoot
+xroot = XendRoot.instance()
+
 class SrvError(error.ErrorPage):
 
     def render(self, request):
@@ -84,7 +87,8 @@ class SrvDir(SrvBase):
                 req.write('<html><head></head><body>')
                 self.print_path(req)
                 self.ls(req)
-                self.form(req)
+		if self.isAuthorized(req):
+                    self.form(req)
                 req.write('</body></html>')
             return ''
         except Exception, ex:
@@ -109,3 +113,22 @@ class SrvDir(SrvBase):
 
     def form(self, req):
         pass
+
+    def render_POST(self, req):
+	if self.isAuthorized(req):
+		return self.perform(req)
+	else:
+		return self.unauthPage(req, "You need admin power.")
+
+    def isAuthorized(self, req):
+	return (req.transport.client[1] < 1024 
+		or not int(xroot.get_xend_privileged_port()))
+
+    def unauthPage(self, req, msg):
+	msg1 = "<p>Connected from %s:%i\n" % \
+		(req.transport.client[0], req.transport.client[1])
+	msg1 += "<Br>Need to connect from privileged port "
+	msg1 += "or set (xend-privileged 0) in xend-config.sxp\n"
+        err = SrvError(http.UNAUTHORIZED, "UNAUTHORIZED", msg + msg1)
+	return err.render(req)
+
diff -uNrp xen-2.0-testing/tools/python/xen/xend/server/SrvDmesg.py xen-2.0-testing.secure/tools/python/xen/xend/server/SrvDmesg.py
--- xen-2.0-testing/tools/python/xen/xend/server/SrvDmesg.py	2005-03-21 04:58:06.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/server/SrvDmesg.py	2005-03-23 13:13:25.647997393 +0100
@@ -15,10 +15,8 @@ class SrvDmesg(SrvDir):
         SrvDir.__init__(self)
         self.xd = XendDmesg.instance()
 
-    def render_POST(self, req):
-        self.perform(req)
-
     def render_GET(self, req):
+	# No access restriction for now    
         try:
             if self.use_sxp(req):
                 req.setHeader("Content-Type", "text/plain")
diff -uNrp xen-2.0-testing/tools/python/xen/xend/server/SrvDomain.py xen-2.0-testing.secure/tools/python/xen/xend/server/SrvDomain.py
--- xen-2.0-testing/tools/python/xen/xend/server/SrvDomain.py	2005-03-21 04:58:10.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/server/SrvDomain.py	2005-03-23 13:13:25.615003159 +0100
@@ -193,9 +193,6 @@ class SrvDomain(SrvDir):
         val = fn(req.args, {'dom': self.dom.id})
         return val
 
-    def render_POST(self, req):
-        return self.perform(req)
-        
     def render_GET(self, req):
         op = req.args.get('op')
         if op and op[0] in ['vifs', 'vif', 'vbds', 'vbd', 'mem_target_set']:
@@ -220,7 +217,8 @@ class SrvDomain(SrvDir):
                 req.write("<code><pre>")
                 PrettyPrint.prettyprint(self.dom.config, out=req)
                 req.write("</pre></code>")
-            self.form(req)
+            if self.isAuthorized(req):
+                self.form(req)
             req.write('</body></html>')
         return ''
 
diff -uNrp xen-2.0-testing/tools/python/xen/xend/server/SrvDomainDir.py xen-2.0-testing.secure/tools/python/xen/xend/server/SrvDomainDir.py
--- xen-2.0-testing/tools/python/xen/xend/server/SrvDomainDir.py	2005-03-21 04:58:10.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/server/SrvDomainDir.py	2005-03-23 13:13:25.597006304 +0100
@@ -116,9 +116,6 @@ class SrvDomainDir(SrvDir):
             out.close()
             return val
 
-    def render_POST(self, req):
-        return self.perform(req)
-
     def render_GET(self, req):
         try:
             if self.use_sxp(req):
@@ -129,7 +126,8 @@ class SrvDomainDir(SrvDir):
                 self.print_path(req)
                 self.ls(req)
                 self.ls_domain(req)
-                self.form(req)
+		if self.isAuthorized(req):
+                    self.form(req)
                 req.write("</body></html>")
             return ''
         except Exception, ex:
diff -uNrp xen-2.0-testing/tools/python/xen/xend/server/SrvNode.py xen-2.0-testing.secure/tools/python/xen/xend/server/SrvNode.py
--- xen-2.0-testing/tools/python/xen/xend/server/SrvNode.py	2005-03-21 04:58:09.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/server/SrvNode.py	2005-03-23 13:14:34.391982867 +0100
@@ -37,9 +37,6 @@ class SrvNode(SrvDir):
         val = fn(req.args, {})
         return val
     
-    def render_POST(self, req):
-        return self.perform(req)
-
     def render_GET(self, req):
         try:
             if self.use_sxp(req):
@@ -54,8 +51,9 @@ class SrvNode(SrvDir):
                 req.write('<ul>')
                 for d in self.info():
                     req.write('<li> %10s: %s' % (d[0], str(d[1])))
+                #if self.isAuthorized(req):
                 req.write('<li><a href="%sdmesg">Xen dmesg output</a>' % url)
-                req.write('<li><a href="%slog>Xend log</a>' % url)
+                req.write('<li><a href="%slog">Xend log</a>' % url)
                 req.write('</ul>')
                 req.write('</body></html>')
             return ''
diff -uNrp xen-2.0-testing/tools/python/xen/xend/server/SrvVnetDir.py xen-2.0-testing.secure/tools/python/xen/xend/server/SrvVnetDir.py
--- xen-2.0-testing/tools/python/xen/xend/server/SrvVnetDir.py	2005-03-21 04:58:11.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/server/SrvVnetDir.py	2005-03-23 13:13:25.641998441 +0100
@@ -18,9 +18,6 @@ class SrvVnet(SrvDir):
         val = self.xvnet.vnet_delete(self.vnetinfo.id)
         return val
 
-    def render_POST(self, req):
-        return self.perform(req)
-        
     def render_GET(self, req):
         if self.use_sxp(req):
             req.setHeader("Content-Type", sxp.mime_type)
@@ -32,7 +29,8 @@ class SrvVnet(SrvDir):
             req.write("<code><pre>")
             PrettyPrint.prettyprint(self.vnetinfo.sxpr(), out=req)
             req.write("</pre></code>")
-            self.form(req)
+	    if self.isAuthorized(req):
+                self.form(req)
             req.write('</body></html>')
         return ''
 
@@ -71,9 +69,6 @@ class SrvVnetDir(SrvDir):
         val = fn(req.args, {})
         return val
         
-    def render_POST(self, req):
-        return self.perform(req)
-
     def render_GET(self, req):
         try:
             if self.use_sxp(req):
@@ -84,7 +79,8 @@ class SrvVnetDir(SrvDir):
                 self.print_path(req)
                 self.ls(req)
                 self.ls_vnet(req)
-                self.form(req)
+		if self.isAuthorized(req):
+		    self.form(req)
                 req.write("</body></html>")
             return ''
         except Exception, ex:
diff -uNrp xen-2.0-testing/tools/python/xen/xend/server/SrvXendLog.py xen-2.0-testing.secure/tools/python/xen/xend/server/SrvXendLog.py
--- xen-2.0-testing/tools/python/xen/xend/server/SrvXendLog.py	2005-03-21 04:58:11.000000000 +0100
+++ xen-2.0-testing.secure/tools/python/xen/xend/server/SrvXendLog.py	2005-03-23 13:13:25.654996170 +0100
@@ -18,6 +18,7 @@ class SrvXendLog(SrvDir):
         self.logfile.encoding = None
 
     def render_GET(self, req):
+	# No access restriction for now    
         try:
             return self.logfile.render(req)
         except Exception, ex:

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] xen-2.0: privileged port connections

[Anthony Liguori]

So, here's my concerns:

1) ports < 1024 are reserved although 732 is currently unassigned
2) unix domain sockets would solve the same problem
3) this approach is not flexible for finer grain control
4) you still have to find a way to deal with the consoles
5) you still have to deal with xfrd

With all that said, I'd like to see this applied as it's better than 
leaving everything out in the open.

Regards,
Anthony Liguori

Kurt Garloff wrote:

>Hi,
>
>as discussed previously, I went ahead and introduced a setting that
>allows you to restrict the stuff you can when controlling xen by
>connecting to the port 8000 unless you connect from a privileged
>port.
>
>I did not yet bother to look at the event port nor did I try to address
>the consoles. The consoles will be done in a second patch if this 
>approach is deemed appropriate. 
>
>Note that I also do still allow unprivileged connections still to gather
>most of the information. This can be debated, but I'm not such a big fan
>of security by obscurity.
>
>I hope I did not miss anything important for the control stuff.
>
>The patch also fixes one typo (missing ") in SrvNode.py.
>
>Regards,
>  
>



-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

Hi Anthony,

On Wed, Mar 23, 2005 at 09:41:24AM -0600, Anthony Liguori wrote:
> So, here's my concerns:
> 
> 1) ports < 1024 are reserved although 732 is currently unassigned

Note that NFS uses such ports without asking prior permission.
I chose 732 because it's unassigned indeed.

> 2) unix domain sockets would solve the same problem

Yes. There's one but: 

With the patch you can currently configure xend from completely
open (xend-address '' and xend-privileged-port 0)
to closed (xend-address 'localhost' and xend-privileged-port 1)
except for root (and stuff I overlooked or did not do yet).

If you go for Unix Domain Sockets instead TCP, you lose the ability
of remote control. Unless you support both.

I did not investigate how difficult to do that would be.
If you have a patch, I'd volunteer to review :-)

> 3) this approach is not flexible for finer grain control

sudo, setuid, ... can provide that.

> 4) you still have to find a way to deal with the consoles

Before I start working on getting the consoles under control, I 
wanted to see whether this approach is acceptable at all.

> 5) you still have to deal with xfrd

It seems to listen on *:8002 ... 
Is there no authentication either? Sigh.

And we probably need to look into the event channel (8001) as well.

> With all that said, I'd like to see this applied as it's better than 
> leaving everything out in the open.

For Xen-3.0, we may want to carefully chose what kind of backend (xend)
to frontend (xm) communication channels we want to allow and how
authentication and authorization is handled there.

But for Xen-2, let's try to find a pragmatic way that enables desktop
users to install and test xen without raising too many security 
concerns.

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] xen-2.0: privileged port connections

[Anthony Liguori]

Kurt Garloff wrote:

>Hi Anthony,
>
>On Wed, Mar 23, 2005 at 09:41:24AM -0600, Anthony Liguori wrote:
>  
>
>>So, here's my concerns:
>>
>>1) ports < 1024 are reserved although 732 is currently unassigned
>>    
>>
>
>Note that NFS uses such ports without asking prior permission.
>I chose 732 because it's unassigned indeed.
>
I know.  That's one of the reasons using this port worries me.  There 
may be nfs related conflicts.

>>4) you still have to find a way to deal with the consoles
>>    
>>
>
>Before I start working on getting the consoles under control, I 
>wanted to see whether this approach is acceptable at all.
>  
>
How would you extend this to consoles?  Each console can't have it's own 
privileged port :-)

>>5) you still have to deal with xfrd
>>    
>>
>
>It seems to listen on *:8002 ... 
>Is there no authentication either? Sigh.
>  
>
Nope.  I think there are a few options.  We could use hosts.allow or 
something similiar, we could restrict it to subnets, or we could try and 
implement some sort of authentication mechanism.

Perhaps shutting it off by default and making it clear that it is 
insecure is enough.

>And we probably need to look into the event channel (8001) as well.
>  
>
Yeah.

>But for Xen-2, let's try to find a pragmatic way that enables desktop
>users to install and test xen without raising too many security 
>concerns.
>  
>
I full-heartedly agree.  I'll gladly help out on this effort.

Regards,
Anthony Liguori

>Regards,
>  
>



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

Hi,

On Wed, Mar 23, 2005 at 11:03:39AM -0600, Anthony Liguori wrote:
> >Note that NFS uses such ports without asking prior permission.
> >I chose 732 because it's unassigned indeed.
> >
> I know.  That's one of the reasons using this port worries me.  There 
> may be nfs related conflicts.

The NFS client just choses a free privileged source port as does xm.
Yes, the amount of NFS mounts is limited ...
And now xen competes with NFS, but neither should really tip over.

> >Before I start working on getting the consoles under control, I 
> >wanted to see whether this approach is acceptable at all.
> > 
> >
> How would you extend this to consoles?  Each console can't have it's own 
> privileged port :-)

Oh, that's what I was planning to do. The privileged ports are less
scarce than the 4GB of memory that Xen-2 supports ...
We'll hardly get running more than 64 virtual machines, I'd guess.

> >>5) you still have to deal with xfrd
> >
> >It seems to listen on *:8002 ... 
> >Is there no authentication either? Sigh.
> >
> Nope.  I think there are a few options.  We could use hosts.allow or 
> something similiar, we could restrict it to subnets, or we could try and 
> implement some sort of authentication mechanism.
> 
> Perhaps shutting it off by default and making it clear that it is 
> insecure is enough.

We need to document it at least. Mazbe another setting in
xend-config.sxp ...

> >And we probably need to look into the event channel (8001) as well.
> >
> Yeah.

Any insight what we could do there?

> >But for Xen-2, let's try to find a pragmatic way that enables desktop
> >users to install and test xen without raising too many security 
> >concerns.
> >
> I full-heartedly agree.  I'll gladly help out on this effort.

Thanks!

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] xen-2.0: privileged port connections

[Nivedita Singhvi]

Kurt Garloff wrote:

>>1) ports < 1024 are reserved although 732 is currently unassigned
> 
> 
> Note that NFS uses such ports without asking prior permission.
> I chose 732 because it's unassigned indeed.

With all due respect to the NFS folks, NFS is just not
a good example to follow in any aspect. Just picking an
unassigned port randomly won't ensure a non-conflict.

>>2) unix domain sockets would solve the same problem
> 
> 
> Yes. There's one but: 
> 
> With the patch you can currently configure xend from completely
> open (xend-address '' and xend-privileged-port 0)
> to closed (xend-address 'localhost' and xend-privileged-port 1)
> except for root (and stuff I overlooked or did not do yet).
> 
> If you go for Unix Domain Sockets instead TCP, you lose the ability
> of remote control. Unless you support both.

> I did not investigate how difficult to do that would be.
> If you have a patch, I'd volunteer to review :-)

Yes, we can do this, allow users to select which protocol
they want. But picking one solution and resolving it's
deficiencies in other ways would be simpler and cleaner
in the long run. Having the user make fewer infrastructure
decisions like this, the better. It also becomes an issue
when the distros need to ship with a fixed config.

>>3) this approach is not flexible for finer grain control
> 
> 
> sudo, setuid, ... can provide that.

The fewer such programs, the better for security, right?

>>4) you still have to find a way to deal with the consoles
> 
> 
> Before I start working on getting the consoles under control, I 
> wanted to see whether this approach is acceptable at all.
> 
> 
>>5) you still have to deal with xfrd
> 
> 
> It seems to listen on *:8002 ... 
> Is there no authentication either? Sigh.
> 
> And we probably need to look into the event channel (8001) as well.

Yep.

>>With all that said, I'd like to see this applied as it's better than 
>>leaving everything out in the open.

Agreed.

> For Xen-3.0, we may want to carefully chose what kind of backend (xend)
> to frontend (xm) communication channels we want to allow and how
> authentication and authorization is handled there.
> 
> But for Xen-2, let's try to find a pragmatic way that enables desktop
> users to install and test xen without raising too many security 
> concerns.

Agreed.

thanks,
Nivedita




-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

RE: [PATCH] xen-2.0: privileged port connections

[Ian Pratt]

> > 1) ports < 1024 are reserved although 732 is currently unassigned
> 
> Note that NFS uses such ports without asking prior permission.
> I chose 732 because it's unassigned indeed.

Grabbing any port <1024 should do, there's no need to just go for 732,
but have a series of ports that are tried. 
 
> > 2) unix domain sockets would solve the same problem
> 
> Yes. There's one but: 
> 
> With the patch you can currently configure xend from completely
> open (xend-address '' and xend-privileged-port 0)
> to closed (xend-address 'localhost' and xend-privileged-port 1)
> except for root (and stuff I overlooked or did not do yet).
> 
> If you go for Unix Domain Sockets instead TCP, you lose the ability
> of remote control. Unless you support both.
> 
> I did not investigate how difficult to do that would be.
> If you have a patch, I'd volunteer to review :-)

For Xen 2.x, unix domain sockets would be too much of a pain to
implement over Twisted. Kurt's approach gets us closer toward 'secure by
default'.

Xen 3 will be very different.

> > 4) you still have to find a way to deal with the consoles
> 
> Before I start working on getting the consoles under control, I 
> wanted to see whether this approach is acceptable at all.

I think it's a good band-aid.

Perhaps a better way to handle consoles would be to use 'screend', and
then have incoming ssh connections dispatched to particular screen
sessions.
 
> > 5) you still have to deal with xfrd
> 
> It seems to listen on *:8002 ... 
> Is there no authentication either? Sigh.
> 
> And we probably need to look into the event channel (8001) as well.

Xfrd needs an option to listen only on localhost. (It's still needed for
save/restore even if you don't use migrate).

The event channel only ever needs to be localhost (and could probably be
turned into a unix domain socket quite easily).


Ian


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_idh83&alloc_id\x15149&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Anthony Liguori]

Kurt Garloff wrote:

>Oh, that's what I was planning to do. The privileged ports are less
>scarce than the 4GB of memory that Xen-2 supports ...
>We'll hardly get running more than 64 virtual machines, I'd guess.
>  
>
Maybe not the typical desktop user but that's definitely not going to be 
the case for the enterprise user.  I do a lot of testing with small 
domUs and I routinely have 40+ domains running (16MB a piece) on my 1GB 
laptop.

On a 4GB system, with NFS in the picture, you could pretty easily 
exhaust the privileged ports with domains using between 32-64MB of 
memory (which is a pretty reasonable amount to allocate).  Throw in PAE 
support and you'll run out quickly.

Would a patch to change Xend to use pty's for consoles be accepted?  xm 
console can be invoked via ssh to support remote consoles..

>Any insight what we could do there?
>  
>
I hate to beat a dead horse, but domain sockets seem like the obvious 
thing to do.  We don't need different privilege levels there so that 
seems like the thing to do.

Regards,Anthony Liguori



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Ryan Harper]

* Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> [2005-03-23 11:50]:
> > Before I start working on getting the consoles under control, I 
> > wanted to see whether this approach is acceptable at all.
> 
> I think it's a good band-aid.
> 
> Perhaps a better way to handle consoles would be to use 'screend', and
> then have incoming ssh connections dispatched to particular screen
> sessions.

Do you have a pointer to this 'screend'?  

Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@us.ibm.com


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Rik van Riel]

On Wed, 23 Mar 2005, Kurt Garloff wrote:

> Oh, that's what I was planning to do. The privileged ports are less
> scarce than the 4GB of memory that Xen-2 supports ...
> We'll hardly get running more than 64 virtual machines, I'd guess.

I would expect ISPs to have more virtual machines than that,
for cheap "root on your own virtual machine" hosting accounts
with larger hardware.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

RE: [PATCH] xen-2.0: privileged port connections

[Ian Pratt]

> Would a patch to change Xend to use pty's for consoles be 
> accepted?  xm 
> console can be invoked via ssh to support remote consoles..

I'm in favour of this in principle, but I think we need to think through
precisely how the pty approach would work. 

There are a couple of other issues that we should consider at the same
time. I've heard a couple of users complain that they find our model of
exporting serial consoles confusing: when they quit a console session
and reconnect they find that they are still logged in. Worse, if they
were running vi when they quit the session they get very confused when
connecting back in. I guess if you're not used to a serial console then
you would find the behaviour confusing. Should we be doing some more
complex terminal emulation?

Using something like 'screen' in dom0 might help, so at least upon
reconnecting the console window is 'refreshed' to show its previous
contents.

The other issue we need to consider is VM migration. Ideally, it should
be completely transparent to someone with a console connection open
(just like it is to someone with an ssh connection open). There are two
ways to do this, either have a console server machine for all the nodes
in a cluster, or hide the disconnect/reconnect in the client terminal
program. If we are using a 'standard' program on the client side (e.g.
ssh in an xterm), then the former is preferable. If for some reason we
choose to use a custom program (e.g. son-of-xencons) then we could
reasonably hide the relocation.

I'd like to see a decent discussion of how best to do consoles before
changing the status quo. 

Thanks,
Ian 


 


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_idh83&alloc_id\x15149&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Anthony Liguori]

Ian Pratt wrote:

>There are a couple of other issues that we should consider at the same
>time. I've heard a couple of users complain that they find our model of
>exporting serial consoles confusing: when they quit a console session
>and reconnect they find that they are still logged in. Worse, if they
>were running vi when they quit the session they get very confused when
>connecting back in. I guess if you're not used to a serial console then
>you would find the behaviour confusing. Should we be doing some more
>complex terminal emulation?
>  
>
Perhaps we could export the console via a pty and then create a screen 
session by executing the equivalent of "screen vm-console domid".

Clients can then connect to it by executing screen -x (instead of 
connecting directly to the pty) and our client could translate C-] to 
C-a C-d to detach from the screen.  Any reconnects will perserve the 
screen of the previous session.

This way, we can still have minimalistic toolchains that provide serial 
style consoles.

>The other issue we need to consider is VM migration. Ideally, it should
>be completely transparent to someone with a console connection open
>(just like it is to someone with an ssh connection open). There are two
>ways to do this, either have a console server machine for all the nodes
>in a cluster, or hide the disconnect/reconnect in the client terminal
>program. If we are using a 'standard' program on the client side (e.g.
>ssh in an xterm), then the former is preferable. If for some reason we
>choose to use a custom program (e.g. son-of-xencons) then we could
>reasonably hide the relocation.
>  
>
One solution would be to do console-forwarding underneath the pty.

If you're migrating from system A to system B and you are using ptys, 
your daemon that's exposing the pty on A simply connects to system B via 
TCP and forwards any data from system B's pty to system A's pty.  This 
forwarding chains nicely (albiet naively) if the vm hops across multiple 
machines in a cluster without closing a console.  You could also be 
smarter and have system B signal system A to reconnect to system C if 
the vm is migrated from system B to system C.

Of course, the naive chaining allows your hopping to cross networks such 
that if system A and B are on one network, and B and C are on a 
different network, it all still works.

A cluster-aware toolchain could forward any new console requests 
directly to system B and the forwarded console would disappear once any 
clients still connected to A disconnect.

This is just one idea.  There may be a better way.

Regards,
Anthony Liguori

>I'd like to see a decent discussion of how best to do consoles before
>changing the status quo. 
>
>Thanks,
>Ian 
>
>
> 
>
>  
>



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Christian Limpach]

On Wed, 23 Mar 2005 13:27:16 -0600, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Perhaps we could export the console via a pty and then create a screen
> session by executing the equivalent of "screen vm-console domid".
> 
> Clients can then connect to it by executing screen -x (instead of
> connecting directly to the pty) and our client could translate C-] to
> C-a C-d to detach from the screen.  Any reconnects will perserve the
> screen of the previous session.

Yes, I think this is what we want.  Although I thought we could
probably change screen's keyboard mapping such that C-] is the escape
character and at the same time finally get support for sending C-] to
the domain -- I keep getting stuck in nested xencons clients...
You can have screen -x as a login shell or run it from command= in a
.ssh/authorized_keys file.

> This way, we can still have minimalistic toolchains that provide serial
> style consoles.

I think it should be an option in the domain configuration file
whether the domain creating tool should also setup a screen session
backing the console.  I think this needs to be somehow linked to the
domain creation tool because otherwise you won't capture the entire
output.
If we support multiple consoles for a single domain, it would also be
nice to have them all connected to the same screen session, allowing
you to switch between the consoles using C-] 1, C-] 2, ...

   christian


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

Hi,

On Wed, Mar 23, 2005 at 09:37:49PM +0000, Christian Limpach wrote:
> If we support multiple consoles for a single domain, it would also be
> nice to have them all connected to the same screen session, allowing
> you to switch between the consoles using C-] 1, C-] 2, ...

With screen, you can at least connect multiple times to the same
console/session.
For the rest, screen inside screen will do :-)

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] xen-2.0: privileged port connections

[David Hopwood]

Kurt Garloff wrote:
> Hi,
> 
> as discussed previously, I went ahead and introduced a setting that
> allows you to restrict the stuff you can when controlling xen by
> connecting to the port 8000 unless you connect from a privileged
> port.

I thought the consensus was to use Unix domain socket-based
restrictions for this?

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Tommi Virtanen]

Ian Pratt wrote:
> For Xen 2.x, unix domain sockets would be too much of a pain to
> implement over Twisted. Kurt's approach gets us closer toward 'secure by
> default'.

That just tells me you don't know twisted
(putting my "Twisted upstream developer" hat on..)

Replace current reactor.listenTCP(port, protocolFactory)
with reactor.listenUNIX(path, protocolFactory).
If there's code that assumes TCP things (transport.getPeer()
to give IP addresses and ports etc), those may need to be fixed,
naturally.

If you would use .tacs, as the recommended Twisted way
of deplying server applications is, that would more like
a configuration file change, done in /etc, as suits the admin.

If you would use strports, that would be switching from
string "8080" to string "unix:/path/to/socket".

The actual protocol mechanics work identically.


-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [PATCH] xen-2.0: privileged port connections

[Anthony Liguori]

On Thu, 2005-03-24 at 13:06, Tommi Virtanen wrote:
> Ian Pratt wrote:
> > For Xen 2.x, unix domain sockets would be too much of a pain to
> > implement over Twisted. Kurt's approach gets us closer toward 'secure by
> > default'.
> 
> That just tells me you don't know twisted
> (putting my "Twisted upstream developer" hat on..)
> 
> Replace current reactor.listenTCP(port, protocolFactory)
> with reactor.listenUNIX(path, protocolFactory).
> If there's code that assumes TCP things (transport.getPeer()
> to give IP addresses and ports etc), those may need to be fixed,
> naturally.

Thanks, I couldn't figure out why exporting the consoles over a domain
socket wasn't working :-)  Turns out we're using .getPeer().

I think perhaps we didn't use twisted as best as we could have so I
agree with that it's going to be a fair bit of work.

Regards,

-- 
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208




-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click