This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] severe security issue on dom0/xend/xm/non-root users

To: Kurt Garloff <kurt@xxxxxxxxxx>
Subject: Re: [Xen-devel] severe security issue on dom0/xend/xm/non-root users
From: Tommi Virtanen <tv@xxxxxxxxxxxxx>
Date: Fri, 18 Mar 2005 11:19:52 +0200
Cc: Philip R Auld <pauld@xxxxxxxxxxx>, David Hopwood <david.hopwood@xxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 19 Mar 2005 01:58:40 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050317150230.GW11685@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <422B1E47.9050502@xxxxxxxxxxxxx> <Pine.LNX.4.61.0503061613160.31720@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20050313145512.GC29310@xxxxxxxxxxxxxxxxx> <4234B2F5.1070205@xxxxxxxxxxxxxxxx> <20050313215122.GC11358@xxxxxxxxxxxxxxxxx> <20050314145850.GB6037@xxxxxxxxxxxxxxxxxx> <20050314151652.GE11417@xxxxxxxxxxxxxxxxx> <20050314155421.GD6037@xxxxxxxxxxxxxxxxxx> <20050314161316.GM11417@xxxxxxxxxxxxxxxxx> <423927DB.3040305@xxxxxxxxxxxxx> <20050317150230.GW11685@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Debian Thunderbird 1.0 (X11/20050116)
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
  - 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.
Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>