IDMS : Weekly status report #1 of 14

[Ambarisha B]

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 at 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