IDMS : Weekly status report #1 of 14
b.ambarisha at gmail.com
Mon Jul 1 07:02:47 UTC 2013
Sorry for the delayed response, I was away from my system for a couple of
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
> 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
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?
More information about the soc-status