Xen devel - Mar 2005 - severe security issue on dom0/xend/xm/non-root users

Bastian informed me on irc of a very severe security problem with xen.  A
normal user can run xm, which then just communicates using tcp to xend, to do
the work.  This allows a normal user to create domains, which then allows a
normal user to be able to access block devices.

Doing chmod 700 on the xm binary won''t help, as the user could just
copy the
files.

My suggestion is to have an auth file of some kind in /etc/xen, chmod 700,
that both xend and xm can then read.  They''d then have to use https to
communicate.  But that''s only if you stick with python.

Unix domain sockets don''t have this problem, as they can query the
userid at
the other end of the socket.



-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Any network user can connect to dom0 and also do any of these
operations.

The Xen documents should perhaps make this more aware.

Xend is not designed to provide any sort of security protection out of
the box.  It assumes that you''re running on a trusted network.  Just
assume that any person that can ping dom0 has root access to your
system.

This is being addressed.  This isn''t a flaw in Xend.  It just
wasn''t
meant for a security-conscious environment.

Regards,
Anthony Liguori

On Fri, 2005-03-04 at 11:23, Adam Heath wrote:
> Bastian informed me on irc of a very severe security problem with xen.  A
> normal user can run xm, which then just communicates using tcp to xend, to
do
> the work.  This allows a normal user to create domains, which then allows a
> normal user to be able to access block devices.
> 
> Doing chmod 700 on the xm binary won''t help, as the user could
just copy the
> files.
> 
> My suggestion is to have an auth file of some kind in /etc/xen, chmod 700,
> that both xend and xm can then read.  They''d then have to use
https to
> communicate.  But that''s only if you stick with python.
> 
> Unix domain sockets don''t have this problem, as they can query the
userid at
> the other end of the socket.
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
-- 
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Anthony Liguori wrote:
>Xend is not designed to provide any sort of security protection out of
>the box.  It assumes that you''re running on a trusted network. 
Just
>assume that any person that can ping dom0 has root access to your
>system.
>  
>
How about the config option that restricts Xend to listening only on the 
loopback network interface?

Rich


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, 4 Mar 2005, Anthony Liguori wrote:
> Any network user can connect to dom0 and also do any of these
> operations.
Very simple to firewall it off from remote, or even only attached to
localhost.
> The Xen documents should perhaps make this more aware.
> Xend is not designed to provide any sort of security protection out of
> the box.  It assumes that you''re running on a trusted network. 
Just
> assume that any person that can ping dom0 has root access to your
> system.
> This is being addressed.  This isn''t a flaw in Xend.  It just
wasn''t
> meant for a security-conscious environment.
Once the xen packages are accepted out of debian''s incoming queue, I
can be
assured of having this bug filed, and it being tagged security.  It *is* a
problem.  Saying it wasn''t designed with this in mind doesn''t
make it a
non-issue.


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, 4 Mar 2005, Anthony Liguori wrote:
> You can''t stop local connections from non-root users but
there''s not a
> whole lot of reason to have non-root users in domain-0 anyway.
Well, you couldn''t, but it''s not the right approach. 
There''s the OWNER
extension to iptables.



-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, 2005-03-04 at 13:19, Rich Persaud wrote:
> Anthony Liguori wrote:
> 
> >Xend is not designed to provide any sort of security protection out of
> >the box.  It assumes that you''re running on a trusted network.
Just
> >assume that any person that can ping dom0 has root access to your
> >system.
> >  
> >
> How about the config option that restricts Xend to listening only on the 
> loopback network interface?
That''s why I was careful to say "out of the box".

There are a number of things you can do to secure Xend.  You can make it
listen to the loopback device, you could use a firewall (which I think
is a more flexible option).

You can''t stop local connections from non-root users but
there''s not a
whole lot of reason to have non-root users in domain-0 anyway.

BTW, Posix doesn''t mandate that filesystem permissions are respected
with unix domain sockets.  Linux currently does check the filesystem
permission bits when opening a unix domain socket.  A few notable Unices
(I think BSD but I''m not sure) don''t perform permission checks
on domain
sockets.

The proper way to do permission checking with domain sockets is using
SCM data.

Regards,
> Rich
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
-- 
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Anthony Liguori wrote:
>We debated this previously with respect to boot loaders.  At the end of
>the day, you just don''t want any code running, no matter how
restricted,
>in dom0 that you don''t trust.
>  
>
While on this subject, has anyone tried running LIDS, grsecurity and/or 
SELinux in dom0?

Rich


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, 2005-03-04 at 13:35, Adam Heath wrote:
> Once the xen packages are accepted out of debian''s incoming queue,
I can be
> assured of having this bug filed, and it being tagged security.  It *is* a
> problem.  Saying it wasn''t designed with this in mind
doesn''t make it a
> non-issue.
I''m not saying it''s a non-issue :-)  It''s one of the
reasons I''m working
on VM-Tools.  Security is not something you can just retro-fit into
something.  It has to be designed in from the beginning.

That said, I don''t think Xend not being secure on a hostile dom0 is a
bug per-say.  Really, having a hostile dom0 is putting an awful lot of
faith in the Linux syscall interface.

Remember, dom0 is a single point of failure.  If dom0 is compromised,
all of your VMs are.

We debated this previously with respect to boot loaders.  At the end of
the day, you just don''t want any code running, no matter how
restricted,
in dom0 that you don''t trust.

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, Mar 04, 2005 at 01:47:35PM -0600, Anthony Liguori
wrote:
> You can''t stop local connections from non-root users but
there''s not a
> whole lot of reason to have non-root users in domain-0 anyway.
Fedora wants to adopt xen and I don''t think they remove the VGA-card
from domain 0.
> BTW, Posix doesn''t mandate that filesystem permissions are
respected
> with unix domain sockets.  Linux currently does check the filesystem
> permission bits when opening a unix domain socket.  A few notable Unices
> (I think BSD but I''m not sure) don''t perform permission
checks on domain
> sockets.
But for directories.
> The proper way to do permission checking with domain sockets is using
> SCM data.
No, it is not.

Bastian

-- 
One does not thank logic.
		-- Sarek, "Journey to Babel", stardate 3842.4


-------------------------------------------------------
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_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, Mar 04, 2005 at 01:54:02PM -0600, Anthony Liguori
wrote:
> I''m not saying it''s a non-issue :-)  It''s one of
the reasons I''m working
> on VM-Tools.  Security is not something you can just retro-fit into
> something.  It has to be designed in from the beginning.
How stable is VM-Tools for a purely single computer Xen system? No
migration features. Just startup and shutdown of domUs. ie. As a
replacement for UML.

> That said, I don''t think Xend not being secure on a hostile dom0
is a
> bug per-say.  Really, having a hostile dom0 is putting an awful lot of
> faith in the Linux syscall interface.
If someone has privileged access to block devices, then there really
isn''t much you can do.

However, doesn''t mean that you can''t work hard to make it
difficult to
abuse. Security after all is a layer approach. The more you do at each
level, the less options an attacker has.

However, delegating all network security to iptables is a bad idea IMO.
Leaves you open for when iptables breaks.


Is it possible to turn off the migration features of xend completely?
ie. remove the need for the network layer.

Nicholas



-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Anthony Liguori wrote:
> BTW, Posix doesn''t mandate that filesystem permissions are
respected
> with unix domain sockets.  Linux currently does check the filesystem
> permission bits when opening a unix domain socket.  A few notable Unices
> (I think BSD but I''m not sure) don''t perform permission
checks on domain
> sockets.
> 
> The proper way to do permission checking with domain sockets is using
> SCM data.
There are several techniques you could be referring to:

<http://www.whitefang.com/sup/secure-faq.html#LOCAL4>
<http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/sockets.html>

but they all sound to me like complicated and nonportable hacks. Which one
did you mean?

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



-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

David Hopwood wrote:
> There are several techniques you could be referring to:
>
> <http://www.whitefang.com/sup/secure-faq.html#LOCAL4>
>
<http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/sockets.html>
>
>
> but they all sound to me like complicated and nonportable hacks. Which 
> one
> did you mean?
SCM_CREDENTIALS on Linux, SCM_CREDS on some versions of BSD, SO_PEERNAME 
on some other Unices.

They all do just about the same thing.  Just have to choose the right 
mechanism at compile time.

Regards,
Anthony Liguori



-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, 4 Mar 2005, Bastian Blank wrote:
> On Fri, Mar 04, 2005 at 01:47:35PM -0600, Anthony Liguori wrote:
> > You can''t stop local connections from non-root users but
there''s not a
> > whole lot of reason to have non-root users in domain-0 anyway.
> 
> Fedora wants to adopt xen and I don''t think they remove the
VGA-card
> from domain 0.
Indeed.  I guess I need to think about restricting connections
to xend to localhost only - and maybe even through a unix
domain socket instead of a tcp socket ...

Note that I do not believe that xend access should be root
only, people may want to run management software under another
UID.  As long as domain 0 doesn''t get any untrusted users,
things should be fine.

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


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Sat, Mar 05, 2005 at 04:53:18PM -0500, Rik van Riel
wrote:
> Indeed.  I guess I need to think about restricting connections
> to xend to localhost only - and maybe even through a unix
> domain socket instead of a tcp socket ...
This are my thoughts about this problem:

----- Forwarded message from Bastian Blank <waldi@debian.org> -----

Date: Sat, 5 Mar 2005 13:38:11 +0100
Subject: proposal for xend communication

I tried to construct a secure-by-default communication between xm and
xend and for access to the consoles.

Communication channels:
 * Configuration: UNIX/TCP socket with the possibility to connect to consoles.
   (This may violate the HTTP protocol.)
 * Console: UNIX/TCP socket.
 * Migration: TCP socket.

By default only the configuration unix socket is enabled and secured by
filesystem permissions on the containing directory. Anything else needs
to be enabled in the config. The domain console option is predefined as
empty.

The domain config console option is changed to a socket spec.
(Examples: ''unix:/tmp/bla'', ''tcp::6703'',
''tcp:0.0.0.0:6704'',
''tcp:192.168.1.2:6705'')

Don''t know yet how to specify the configuration and migration sockets
in
the overall config.

----- End forwarded message -----

Bastian

-- 
He''s dead, Jim.
		-- McCoy, "The Devil in the Dark", stardate 3196.1

Rik van Riel wrote:
> Note that I do not believe that xend access should be root
> only, people may want to run management software under another
> UID.  As long as domain 0 doesn''t get any untrusted users,
> things should be fine.
That''s not good design. I sincerely think access to any confidential
or security conscious part of xen should be limited, e.g. with a
unix domain socket located in a directory only readable by a certain
group.

If any user in dom0 can do sensitive xm operations, a security bug
in _any_ dom0 networked app allows the attacker to gain remote root.
That is, (xen trusts every user in dom0) implies (in dom0, all security
vulnerabilities give access to root).

Note that if there are harmless xm commands (xm list and so on), they
could be allowed for all users in dom0.


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Sun, 6 Mar 2005, Tommi Virtanen wrote:
> Rik van Riel wrote:
> > Note that I do not believe that xend access should be root
> > only, people may want to run management software under another
> > UID.  As long as domain 0 doesn''t get any untrusted users,
> > things should be fine.
> 
> That''s not good design. I sincerely think access to any
confidential
> or security conscious part of xen should be limited, e.g. with a
> unix domain socket located in a directory only readable by a certain
> group.
Good point, then we could use filesystem permissions
and/or selinux policy to restrict who gets access to
xend.
> Note that if there are harmless xm commands (xm list and so on), they
> could be allowed for all users in dom0.
This would require either access permission checks inside
xend, or a separate socket for only unprivileged operations.

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


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi Rik,

On Sun, Mar 06, 2005 at 04:14:24PM -0500, Rik van Riel
wrote:
> On Sun, 6 Mar 2005, Tommi Virtanen wrote:
> > That''s not good design. I sincerely think access to any
confidential
> > or security conscious part of xen should be limited, e.g. with a
> > unix domain socket located in a directory only readable by a certain
> > group.
> 
> Good point, then we could use filesystem permissions
> and/or selinux policy to restrict who gets access to
> xend.
Why not just require the other end of the socket to be below 1024?
If you bind to localhost, that should be enough.

xm would then use a privileged socket if it can (i.e. if called as 
root).

Using an selinux policy for this would be aiming cannons at sparrows
(german saying, in english that''s breaking a fly on the wheel).
> > Note that if there are harmless xm commands (xm list and so on), they
> > could be allowed for all users in dom0.
> 
> This would require either access permission checks inside
> xend, or a separate socket for only unprivileged operations.
Then defer the client[1] port check to the command parser.

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]

On Sun, 13 Mar 2005, Kurt Garloff wrote:
> On Sun, Mar 06, 2005 at 04:14:24PM -0500, Rik van Riel wrote:
> > On Sun, 6 Mar 2005, Tommi Virtanen wrote:
> > > That''s not good design. I sincerely think access to any
confidential
> > > or security conscious part of xen should be limited, e.g. with a
> > > unix domain socket located in a directory only readable by a
certain
> > > group.
> > 
> > Good point, then we could use filesystem permissions
> > and/or selinux policy to restrict who gets access to
> > xend.
> 
> Why not just require the other end of the socket to be below 1024?
> If you bind to localhost, that should be enough.
Because the ability to open connections from ports < 1024
is a capability, which can be retained by daemons after
dropping the other root privileges.
> Using an selinux policy for this would be aiming cannons at sparrows
> (german saying, in english that''s breaking a fly on the wheel).
Don''t forget to read the filesystem permissions part ;)
SELinux policy won''t be required, it just could be used
as a further restriction beyond that offered by the
filesystem permissions.

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


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi Rik,

On Sun, Mar 13, 2005 at 11:00:27AM -0500, Rik van Riel
wrote:
> On Sun, 13 Mar 2005, Kurt Garloff wrote:
> > Why not just require the other end of the socket to be below 1024?
> > If you bind to localhost, that should be enough.
> 
> Because the ability to open connections from ports < 1024
> is a capability, which can be retained by daemons after
> dropping the other root privileges.
Right.
But I don''t see a problem with this.

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]

> > On Sun, 13 Mar 2005, Kurt Garloff wrote:
> > > Why not just require the other end of the socket to be below
1024?
> > > If you bind to localhost, that should be enough.
> > 
> > Because the ability to open connections from ports < 1024
> > is a capability, which can be retained by daemons after
> > dropping the other root privileges.
I think this is a good first step, and pretty easy to implement.
Volunteers?

With the next generation of tools we could insist on using SSL and thus
that the client have an appropriate certificate.

Thanks,
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://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi Ian,

On Sun, Mar 13, 2005 at 05:17:38PM -0000, Ian Pratt
wrote:
> I think this is a good first step, and pretty easy to implement.
... if you know twisted well enough. I did not invest much time,
but I failed.

I had a short look and thought that adding something like

    def connectionMade(self):
       if self.transport:
           log.info("xend: connect from host %s, port %ui" % \
                       (self.transport.client[0], self.transport.client[1]))
           if self.transport.client[1] >= 1024:
               self.loseConnection()

to class EventProtocol in SrvDaemon.py would do the job.

I was wrong ... the log.info never even triggered.

Making this configurable would be a plus as well, I guess.
in XendRoot.py, I had put

    """Default for xend-privileged """
    xend_privileged_default   = ''1''

[...]
    def get_xend_privileged(self):
       """Get the setting that controls whether xend only accepts
connections
       from privileged ports.
       """
       return self.get_config_value(''xend-privileged'',
self.xend_privileged_default)


And then these pieces would need to be connected.
And xm taught to try grabbing a privileged port.
> Volunteers?
Someone more familiar with the xend implementation should be more
successful than me.
> With the next generation of tools we could insist on using SSL and thus
> that the client have an appropriate certificate.
That''s the full blown approach, of course, as it would enable you to
allow remote control.

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]

Kurt Garloff wrote:
> On Sun, Mar 06, 2005 at 04:14:24PM -0500, Rik van Riel wrote:
>>On Sun, 6 Mar 2005, Tommi Virtanen wrote:
>>
>>>That''s not good design. I sincerely think access to any
confidential
>>>or security conscious part of xen should be limited, e.g. with a
>>>unix domain socket located in a directory only readable by a certain
>>>group.
>>
>>Good point, then we could use filesystem permissions
>>and/or selinux policy to restrict who gets access to
>>xend.
> 
> Why not just require the other end of the socket to be below 1024?
Please don''t. The permission should be something that can be
specifically
granted to a user or group id, not that requires root. Requiring root
tends to cause as many security problems as it solves.
> If you bind to localhost, that should be enough.
> 
> xm would then use a privileged socket if it can (i.e. if called as 
> root).
> 
> Using an selinux policy for this would be aiming cannons at sparrows
> (german saying, in english that''s breaking a fly on the wheel).
"using a sledgehammer to crack a nut".

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



-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi David,

On Sun, Mar 13, 2005 at 09:39:01PM +0000, David Hopwood
wrote:
> Kurt Garloff wrote:
> >Why not just require the other end of the socket to be below 1024?
> 
> Please don''t. The permission should be something that can be
specifically
> granted to a user or group id, not that requires root. Requiring root
> tends to cause as many security problems as it solves.
I disagree.

Normally, you''d expect that only the sysadmin is able to control
virtual machines. This would be the result of this simple tweak.

Security problems start when you start using setuid to grant this
privilege to others; to make it secure, we''d need to bind a socket
and then drop all privileges. Not too hard to do in a secure way
IMVHO.
> >Using an selinux policy for this would be aiming cannons at sparrows
> >(german saying, in english that''s breaking a fly on the
wheel).
> 
> "using a sledgehammer to crack a nut".
:-)

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]

Rumor has it that on Sun, Mar 13, 2005 at 10:51:22PM +0100 Kurt Garloff
said:
> Hi David,
> 
> On Sun, Mar 13, 2005 at 09:39:01PM +0000, David Hopwood wrote:
> > Kurt Garloff wrote:
> > >Why not just require the other end of the socket to be below 1024?
> > 
> > Please don''t. The permission should be something that can be
specifically
> > granted to a user or group id, not that requires root. Requiring root
> > tends to cause as many security problems as it solves.
> 
> I disagree.
> 
> Normally, you''d expect that only the sysadmin is able to control
> virtual machines. This would be the result of this simple tweak.
> 
Which sysadmin?  Dom0 sysadmin may not be the same as a vm''s sysadmin.
You would not want a VM sysadmin to be able to manage someone else''s
VM,
but he may want control over his own. 


Cheers,

Phil


-- 
Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Mon, Mar 14, 2005 at 09:58:50AM -0500, Philip R Auld
wrote:
> Rumor has it that on Sun, Mar 13, 2005 at 10:51:22PM +0100 Kurt Garloff
said:
> > Normally, you''d expect that only the sysadmin is able to
control
> > virtual machines. This would be the result of this simple tweak.
> 
> Which sysadmin?  Dom0 sysadmin may not be the same as a vm''s
sysadmin.
> You would not want a VM sysadmin to be able to manage someone
else''s VM,
> but he may want control over his own. 
The most straightforward approach would be to have dom0 sysadmin to be
the one in control of all the other domains.

Currently all dom0 users are, which is inconvenient, as machines that
are used as desktops will need to have dom0 uers.

Of course, the other domains can have their own root users. This is
not changed by restricting control connections to be originating from
ports < 1024.

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]

Rumor has it that on Mon, Mar 14, 2005 at 04:16:52PM +0100 Kurt Garloff
said:
> On Mon, Mar 14, 2005 at 09:58:50AM -0500, Philip R Auld wrote:
> > Rumor has it that on Sun, Mar 13, 2005 at 10:51:22PM +0100 Kurt
Garloff said:
> > > Normally, you''d expect that only the sysadmin is able to
control
> > > virtual machines. This would be the result of this simple tweak.
> > 
> > Which sysadmin?  Dom0 sysadmin may not be the same as a vm''s
sysadmin.
> > You would not want a VM sysadmin to be able to manage someone
else''s VM,
> > but he may want control over his own. 
> 
> The most straightforward approach would be to have dom0 sysadmin to be
> the one in control of all the other domains.
> 
That''s not really ideal for a virtualized environment. Think of a
hosting
setup for example. You''d really like to have the "hoster"
control dom0, but
have roles that allow a vm sysadmin to control his domain. Console and 
power/reset only perhaps, but still some xend access.
> Currently all dom0 users are, which is inconvenient, as machines that
> are used as desktops will need to have dom0 uers.
> 
> Of course, the other domains can have their own root users. This is
> not changed by restricting control connections to be originating from
> ports < 1024.

I''m not arguing against that. I was just pointing out the difference in
roles needed. I think that will actually be orthagonal to protecting
xend itself. Make it secure first then carefully allow access for roles.
The tools will need to handle this permission I think. 


Cheers,

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


-- 
Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Mon, Mar 14, 2005 at 10:54:21AM -0500, Philip R Auld
wrote:
> Rumor has it that on Mon, Mar 14, 2005 at 04:16:52PM +0100 Kurt Garloff
said:
> > The most straightforward approach would be to have dom0 sysadmin to be
> > the one in control of all the other domains.
> 
> That''s not really ideal for a virtualized environment. Think of a
hosting
> setup for example. You''d really like to have the
"hoster" control dom0, but
> have roles that allow a vm sysadmin to control his domain. Console and 
> power/reset only perhaps, but still some xend access.
Agreed.
> > Of course, the other domains can have their own root users. This is
> > not changed by restricting control connections to be originating from
> > ports < 1024.
> 
> I''m not arguing against that. I was just pointing out the
difference in
> roles needed. I think that will actually be orthagonal to protecting
> xend itself. Make it secure first then carefully allow access for roles.
> The tools will need to handle this permission I think. 
I agree.

Currently xend just accepts every command that it receives.
Not a good basis to grant role based permissions ...

So, we need to have some restrictions first, so tools can
grant them for the right people.

And my suggestion was binding to localhost only and requiring a port 
< 1024 -- then you''d need to be a local user with
CAP_NET_BIND_SERVICE
capability.  Granting additional rights by providing this capability 
from a setuid root wrapper (or a PAM service that sets this on login)
should not be too hard and straightforward enough to not introduce
another load of security holes.

The disadvantage of this is that it''s a all or nothing approach.
xend could be made more clever and require the user to show
different certificates for different operations on different
domains. But this is no short term solution.

It would give a rather large matrix of certificates, one dimension
being the kind of operation (list, restart, sysrq, balloon, scheduler,
save/restrore, migrate, ...), another one being the domain. We could
have master certificates for both directions, of course.


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]

Kurt Garloff wrote:
>I agree.
>
>Currently xend just accepts every command that it receives.
>Not a good basis to grant role based permissions ...
>  
>
One approach to role based permissions is to have dom0 enforce 
policies.  Another approach is to enforce policies at the hypervisor 
level which is what sHype does.

One problem with any sort of Xend-level policies is managing 
authentication in a large network.  Especially if you start dealing with 
certificates (you''ve got to tie Xend into a larger certificate 
distribution system).

I think relying on local authentication is a useful approach.  Policies 
can be enforced at group/user granularities and you get every pam/nss 
based sign-on solution for free.

You''re restricted by the Unix user model (small groups, no nested 
groups, etc.) but you gain an awful lot of additional functionality.

Regards,
Anthony Liguori
>So, we need to have some restrictions first, so tools can
>grant them for the right people.
>
>And my suggestion was binding to localhost only and requiring a port 
>< 1024 -- then you''d need to be a local user with
CAP_NET_BIND_SERVICE
>capability.  Granting additional rights by providing this capability 
>from a setuid root wrapper (or a PAM service that sets this on login)
>should not be too hard and straightforward enough to not introduce
>another load of security holes.
>
>The disadvantage of this is that it''s a all or nothing approach.
>xend could be made more clever and require the user to show
>different certificates for different operations on different
>domains. But this is no short term solution.
>
>It would give a rather large matrix of certificates, one dimension
>being the kind of operation (list, restart, sysrq, balloon, scheduler,
>save/restrore, migrate, ...), another one being the domain. We could
>have master certificates for both directions, of course.
>
>
>Regards,
>  
>


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Kurt Garloff wrote:
> And my suggestion was binding to localhost only and requiring a port 
> < 1024 -- then you''d need to be a local user with
CAP_NET_BIND_SERVICE
> capability.  Granting additional rights by providing this capability 
> from a setuid root wrapper (or a PAM service that sets this on login)
> should not be too hard and straightforward enough to not introduce
> another load of security holes.
There''s a simple reason why that''s not really what you want.

Imagine two security-sensitive services, with different sets of
allowed users. Using UNIX domain sockets with filesystem access
control allows using two groups to list the allowed users for each
service -- using <1024 source port does not.

Please use UNIX domain sockets.


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi,

On Thu, Mar 17, 2005 at 08:46:51AM +0200, Tommi Virtanen
wrote:
> There''s a simple reason why that''s not really what you
want.
> 
> Imagine two security-sensitive services, with different sets of
> allowed users. Using UNIX domain sockets with filesystem access
> control allows using two groups to list the allowed users for each
> service -- using <1024 source port does not.
It does.
The frontend (that would acquire the privileged socket) would need
to be setuid root for this and then could enforce whatever policies,
much more flexible than the Unix group membership model if you want.

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

Kurt Garloff wrote:
>>There''s a simple reason why that''s not really what you
want.
>>
>>Imagine two security-sensitive services, with different sets of
>>allowed users. Using UNIX domain sockets with filesystem access
>>control allows using two groups to list the allowed users for each
>>service -- using <1024 source port does not.
> 
> It does.
> The frontend (that would acquire the privileged socket) would need
> to be setuid root for this and then could enforce whatever policies,
> much more flexible than the Unix group membership model if you want.
Oh, the group-restricted UNIX domain socket wins there, too.

Your model:

   - setuid client that only lets certain users open ports <1024

My model:

   - setgid client that only lets certain users connect to the protected
     socket
OR
   - just add the certain users to the group, and let them access the
     protected socket.

The UNIX domain socket way is both more flexible and _more secure_
-- it only needs setgid where the port<1024 thing needs setuid.


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi,

On Fri, Mar 18, 2005 at 11:19:52AM +0200, Tommi Virtanen
wrote:
> Oh, the group-restricted UNIX domain socket wins there, too.
I''m not convinced.
> Your model:
> 
>   - setuid client that only lets certain users open ports <1024
You''re very flexible in your setuid root client.

1. You may restrict the set of users that is able to call the client,
   e.g. it might be root:trusted 4750. This would impose the same 
   restrictions as your group protection mechanism. 
2. The first thing the client does it to acquire the privileged 
   port and then drop capabilities immediately afterwards. Security
   flaws in the client will thus at most grant the exploiter a
   privileged socket. (This has nothing to do with xen, just a
   general rule for setuid root apps.)
3. The client can impose whatever restrictions it likes, e.g.
   checking SSL certificates, asking for passwords, checking
   a configuration file, whatever.
> The UNIX domain socket way is both more flexible and _more secure_
> -- it only needs setgid where the port<1024 thing needs setuid.
I don''t see a big difference in neither flexibility nor security.
So let''s create patches and see which one looks better in the end :-)

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]

Kurt Garloff wrote:
> You''re very flexible in your setuid root client.
> 
> 1. You may restrict the set of users that is able to call the client,
>    e.g. it might be root:trusted 4750. This would impose the same 
>    restrictions as your group protection mechanism. 
With the group-protected unix domain socket, you don''t need any code
to do that.
> 2. The first thing the client does it to acquire the privileged 
>    port and then drop capabilities immediately afterwards. Security
>    flaws in the client will thus at most grant the exploiter a
>    privileged socket. (This has nothing to do with xen, just a
>    general rule for setuid root apps.)
With the group-protected unix domain socket, security flaws in the
client will at most grant a not-used-for-anything-else group membership,
which allows one to connect to the xend socket.

That is, security flaws in the client will never be able to directly
give the attacker root access.

Also, xend can only be attacked by people in the group, where as
xend listening on 127.0.0.1 can be attacked by any local user.
> 3. The client can impose whatever restrictions it likes, e.g.
>    checking SSL certificates, asking for passwords, checking
>    a configuration file, whatever.
That''s equally true for unix domain sockets.
> I don''t see a big difference in neither flexibility nor security.
So you really _want_ to add yet another unnecessary setuid app, where
one really is not needed?


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Tommi Virtanen wrote:
> Kurt Garloff wrote:
> 
>> The frontend (that would acquire the privileged socket) would need
>> to be setuid root for this and then could enforce whatever policies,
>> much more flexible than the Unix group membership model if you want.
> 
> Oh, the group-restricted UNIX domain socket wins there, too.
> 
> Your model:
> 
>   - setuid client that only lets certain users open ports <1024
> 
> My model:
> 
>   - setgid client that only lets certain users connect to the protected
>     socket
> OR
>   - just add the certain users to the group, and let them access the
>     protected socket.
> 
> The UNIX domain socket way is both more flexible and _more secure_
> -- it only needs setgid where the port<1024 thing needs setuid.
Agree 100%. There are no advantages to the port<1024 method over using
Unix domain sockets.

Kurt Garloff wrote:
> You''re very flexible in your setuid root client.
> 
> 1. You may restrict the set of users that is able to call the client,
>    e.g. it might be root:trusted 4750. This would impose the same 
>    restrictions as your group protection mechanism. 
> 2. The first thing the client does it to acquire the privileged 
>    port and then drop capabilities immediately afterwards. Security
>    flaws in the client will thus at most grant the exploiter a
>    privileged socket. (This has nothing to do with xen, just a
>    general rule for setuid root apps.)
> 3. The client can impose whatever restrictions it likes, e.g.
>    checking SSL certificates, asking for passwords, checking
>    a configuration file, whatever.
You can 1 and 3 just as easily with the Unix domain socket method.
Although you could also do 2, there''s no need (2 is not a flexibility
advantage, it''s just something you have to do to make the port<1024
method secure).

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



-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

David Hopwood wrote:
> You can 1 and 3 just as easily with the Unix domain socket method.
> Although you could also do 2, there''s no need (2 is not a
flexibility
> advantage, it''s just something you have to do to make the
port<1024
> method secure).
More importantly, using SCM_CREDENTIALS allows you to pass the actual 
user credentials overs the domain socket.

This is by far the best mechanism as it allows access control to be 
implemented entirely within the daemon without doing any nasty set[ug]id 
trickery.  Its entire purpose in life is doing exactly what we''re
trying
to do :-)

Regards,
Anthony Liguori


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Tommi Virtanen wrote:
> Kurt Garloff wrote:
>> I don''t see a big difference in neither flexibility nor
security.
>
> So you really _want_ to add yet another unnecessary setuid app,
> where one really is not needed?
Tommi has said everything already, and I concur - please consider
using an UNIX-domain socket. Even more reasons for preferring it over
a TCP-connection can be listed, but hopefully they are not needed.

-- Naked




-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel