Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Jul 2013 12:32:46 +0530
From:      Ambarisha B <b.ambarisha@gmail.com>
To:        David Chisnall <theraven@freebsd.org>
Cc:        soc-status@freebsd.org
Subject:   Re: IDMS : Weekly status report #1 of 14
Message-ID:  <CAJP25sNG0eWVq=ohEkuGQB9A2WnSVQBuv8PXOQ%2BYJaA=xm7aAQ@mail.gmail.com>
In-Reply-To: <00D9C707-D223-44D3-B57F-2FFB0CD028A6@FreeBSD.org>
References:  <CAJP25sPc3%2B-EG8CFsrsHQf5=6JRyioMoABt213sccWbEiTwO=g@mail.gmail.com> <00D9C707-D223-44D3-B57F-2FFB0CD028A6@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <theraven@freebsd.org>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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJP25sNG0eWVq=ohEkuGQB9A2WnSVQBuv8PXOQ%2BYJaA=xm7aAQ>