From owner-soc-status@FreeBSD.ORG Mon Jul 1 07:02:47 2013 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7178B5BC; Mon, 1 Jul 2013 07:02:47 +0000 (UTC) (envelope-from b.ambarisha@gmail.com) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 243B911DB; Mon, 1 Jul 2013 07:02:47 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id hr11so1719893vcb.6 for ; Mon, 01 Jul 2013 00:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZkpAHVQPL+4kIeYDi5RL5H1CW+6RJpoXApcz47YNQBY=; b=MRyLqGN8WlcJCieSh0ivU72/2HY9nU5Ks17eLiglT+XK1WOLzT2Y6wDSAkrKbEP6eT 38ibJ9CxcVyv73ssYIjpPUX7Gs93Z7hnmyl8mRxKcWJZ8zaUKxANVlMGdAXI5pS3Agvv KSRH6IWlVBRyV85vVhAtd36/gy01eMG+euffPDI5Fm6WMAEDKux/8LPl+Ppl49zsmkEa oF3tn7s/OznV1DEXuvNVXjyT4NxWhI91XKm6YwqYEWX6w5rqNo/YHdXVc7PEpwNp6B8Q jOSfSFrcMQHfPrXjEE7QFslkfszyzCjuFHH0ugg5bjWuI/hrQFimoF7bnNH3zmQXE5EF SAXA== MIME-Version: 1.0 X-Received: by 10.58.24.201 with SMTP id w9mr9248822vef.82.1372662166669; Mon, 01 Jul 2013 00:02:46 -0700 (PDT) Received: by 10.58.74.37 with HTTP; Mon, 1 Jul 2013 00:02:46 -0700 (PDT) In-Reply-To: <00D9C707-D223-44D3-B57F-2FFB0CD028A6@FreeBSD.org> References: <00D9C707-D223-44D3-B57F-2FFB0CD028A6@FreeBSD.org> Date: Mon, 1 Jul 2013 12:32:46 +0530 Message-ID: Subject: Re: IDMS : Weekly status report #1 of 14 From: Ambarisha B To: David Chisnall Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: soc-status@freebsd.org X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 07:02:47 -0000 Hi, Sorry for the delayed response, I was away from my system for a couple of days. On Thu, Jun 27, 2013 at 6:42 PM, David Chisnall wrote: > The fetch utility has been the case study for a lot of the > compartmentalisation work on Capsicum so far. Have you considered how the > download manager will handle exploitable bugs in, for example, the HTTP > header parsing in libfetch? Actually I was not sure how much of libfetch can be used in the download manager service at all, because we're thinking of profiling the download speed etc. > I note that your plan is to use a thread, rather than a forked process, > for each request, which means that it can not run in sandboxed mode. > I was not aware of the concerns with fetch that you pointed out. But I don't see any serious drawbacks with doing forked processes as opposed to threads. I don't think process creation overhead is a problem anyways, considering that there is a network transaction involved. Originally I thought forked processes were unnecessary because I was not aware of the sandboxing mode etc. Even now I'll have to take a closer look into it. > What privilege do you imagine the daemon running with? One of the > problems with fetch currently is that it is often invoked as root when > downloading ports distfiles and so runs with ambient privilege of the root > user. > I think the daemon just needs to run as a separate "trusted" user (because it handles the requests of various users, also consider the case when root requests the service for a file). So, even if there is a vulnerability in the daemon, it is contained (till root makes a request atleast). What is the right way to design this? Cheers Ambarish