Date: Mon, 1 Jul 2013 09:36:23 +0100 From: David Chisnall <theraven@freebsd.org> To: Ambarisha B <b.ambarisha@gmail.com> Cc: soc-status@freebsd.org Subject: Re: IDMS : Weekly status report #1 of 14 Message-ID: <6D41292D-0E9B-4760-8345-CAF4D96D2E8F@freebsd.org> In-Reply-To: <CAJP25sNG0eWVq=ohEkuGQB9A2WnSVQBuv8PXOQ%2BYJaA=xm7aAQ@mail.gmail.com> References: <CAJP25sPc3%2B-EG8CFsrsHQf5=6JRyioMoABt213sccWbEiTwO=g@mail.gmail.com> <00D9C707-D223-44D3-B57F-2FFB0CD028A6@FreeBSD.org> <CAJP25sNG0eWVq=ohEkuGQB9A2WnSVQBuv8PXOQ%2BYJaA=xm7aAQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_41382BC6-AD88-4E46-9E27-41AC70ABC547 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 1 Jul 2013, at 08:02, Ambarisha B <b.ambarisha@gmail.com> wrote: > Hi, >=20 > Sorry for the delayed response, I was away from my system for a couple = of days. >=20 > 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? >=20 > 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.=20 If functionality that you need is not available in libfetch, then it = should probably be added. For example, adding a callback that will be = invoked during downloading to update status messages. >> 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. >=20 > 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. Thank you. >> 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. >=20 > 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? Ideally, the daemon should run in sandboxed (cap_enter()) mode for each = worker and should run as an unprivileged user for the daemon. The flow = I would expect would be: - Root (or other) user runs command to get a distfile. This passes the = URL and a file descriptor opened for writing to the daemon - Daemon receives message containing URL from a command and parses the = protocol and the remote host - Daemon opens socket for the connection. - Daemon forks worker - Worker calls cap_enter() - Worker invokes libfetch to get file from remote server and write it to = the file descriptor that it inherits from the parent process - Worker may provide status messages to the parent - Worker exits - Daemon or original command validates the download's hash The most vulnerable part is the worker, as it is the only part that is = talking directly to a remote server (which may be a not-so-trusted and = potentially compromised mirror). If the server is compromised then it = can inject headers or other control messages designed to exploit bugs in = libfetch. These are contained by being in sandboxed mode - all that it = can do maliciously is write bad data to the file, which a compromised = server could do anyway by just providing you with bad data. =20 The validation of the download against the distfile hash is performed = outside of the worker, so a compromised worker can not circumvent this. We assume that the URL is not malicious, because someone who can provide = a malicious URL can also provide a hash and URL for a malicious distfile = and just give you a trojaned program to run later. =20 Optionally, the daemon may chroot() itself to an empty directory = somewhere before dropping privileges. It only needs to be unsandboxed = to be able to open network connections. David --Apple-Mail=_41382BC6-AD88-4E46-9E27-41AC70ABC547 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR0T+IAAoJEKx65DEEsqId7J4QAIWhHnXuo/nSQFuIbm9/O02v W4uhMy+U8IlLHlexTqAo6/CfnP0CVA94rS/6CDfF00q6Q3pjAS5FNb0iqRKRfFAi 41NbhcaTdX+Ry04BVC7/obIrm4gUixBzYKihnCvkZbEwwnxttb2QoR+z8WwKFBBY kEPK7KPVVuhsgIib5LRFrmYCM57/4hptZWirbj4Sev0N3Eptd5ersD7UPElNLzeH Fvdx6KBvRRunbcwmApDxF/IF1zOcmkyiQNG726EnqQhJ3A74UG0xD49J+Ia9PvJw gOqdGVDCi7qeGbgrcXsxlQGLtBtNJwzQlBqe/5KbSuZv/HS1kBT3qP8OZlsvR/7Q 80tGIl/o/Lyh7mCAnGqFsNVgHjfzQ1akEuHQo/K8BuTxx8/jSOggVpYyJ/v8KZ0k nQqG5NV+h4yUL4r1xmiZV/L6C8fAZzD6gDqIoWKgFkzpLLLRC/FFn2mfDpSZ/+Cz zL6oZRyWDiOb31VHxPDcAX18rO/UaOqcUJG2K1ECHTsWuzMUHk/y2wg/m+qNvBn4 e7PzcSngJrEMZNUQfAQmXcuIf4NkJiwFa47tT4sbUYAewzEtZdcC+eK0TK4X4SRB 08ToIaV2NucOHjlD3Dpvf6EfYN9OLGtJszhobO6OCVZU89lz6US39+JbTcUruJQi GGNqX9Jc4FgiO6rUbcRH =39Dv -----END PGP SIGNATURE----- --Apple-Mail=_41382BC6-AD88-4E46-9E27-41AC70ABC547--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6D41292D-0E9B-4760-8345-CAF4D96D2E8F>