From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 5FECBE00769; Fri, 19 Sep 2014 04:26:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from dan.rpsys.net (5751f4a1.skybroadband.com [87.81.244.161]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 47F45E006EF for ; Fri, 19 Sep 2014 04:26:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id s8JBQWP4030396; Fri, 19 Sep 2014 12:26:32 +0100 Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AsGKIXrKL1qP; Fri, 19 Sep 2014 12:26:32 +0100 (BST) Received: from [192.168.3.10] ([192.168.3.10]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id s8JBQRQs030393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Sep 2014 12:26:28 +0100 Message-ID: <1411125990.4736.18.camel@ted> From: Richard Purdie To: "Damian, Alexandru" Date: Fri, 19 Sep 2014 12:26:30 +0100 In-Reply-To: References: X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Cc: "toaster@yoctoproject.org" Subject: Re: FW: [RFC] blacklisted variables X-BeenThere: toaster@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Web based interface for BitBake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 11:26:46 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Fri, 2014-09-19 at 11:56 +0100, Damian, Alexandru wrote: > ​Difficult to say; it's in the interest of those who would run toaster > services open to the public.​ > > If we would be the ones to host the Toaster service, the effort would > have to be supported by probably the whole Yocto team; we need to > look ​into vulnerabilities that can be triggered by setting variables, > e.g. remote code executions - I guess that Richard and Paul should > take a look at how variables can be exploited in Bitbake, and then we > need to audit the core layers too, since basically each recipe can do > whatever it chooses with variables. The nature of the way the metadata works is such that if you allow the user any variable or metadata access, its like giving them a shell account as the build user. I don't see any way to change that and any of these audits are just going to hide the problem, not solve it since fundamentally, bitbake is a code execution engine. A simple example is setting a variable to ${@" ".join(open("/etc/shadow", "r").readlines())}. You could call into your own function which opens up a socket and starts an ssh server quite easily. The structure of any public offering therefore needs to be structured such that there are accounts and those accounts are controlled in some way. The actual build slaves need to be monitored and probably firewalled with the slave user accounts suitably locked down. Cheers, Richard