From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hopwood Subject: Re: severe security issue on dom0/xend/xm/non-root users Date: Sat, 19 Mar 2005 02:33:26 +0000 Message-ID: <423B8F76.9060602@blueyonder.co.uk> References: <422B1E47.9050502@tv.debian.net> <20050313145512.GC29310@tpkurt.garloff.de> <4234B2F5.1070205@blueyonder.co.uk> <20050313215122.GC11358@tpkurt.garloff.de> <20050314145850.GB6037@vienna.egenera.com> <20050314151652.GE11417@tpkurt.garloff.de> <20050314155421.GD6037@vienna.egenera.com> <20050314161316.GM11417@tpkurt.garloff.de> <423927DB.3040305@tv.debian.net> <20050317150230.GW11685@tpkurt.garloff.de> <423A9D38.9080601@tv.debian.net> Reply-To: david.nospam.hopwood@blueyonder.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <423A9D38.9080601@tv.debian.net> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org 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 ------------------------------------------------------- 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