From owner-freebsd-ports@FreeBSD.ORG Mon Oct 7 13:37:59 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D80149E1 for ; Mon, 7 Oct 2013 13:37:59 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6448A242A for ; Mon, 7 Oct 2013 13:37:59 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id z5so5703856lbh.0 for ; Mon, 07 Oct 2013 06:37:57 -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:content-transfer-encoding; bh=JRiXTCoVQESn24uVXeiJDKXiWApYA+hQEG3gBgqaCRk=; b=APBYQkSx/Iy7ouJgtVgQNkb+XHf1ss9kZGxJH/ZilCqpUBgnqbR7oouB7X3zhNdPLR h/0yO9SFRiiSmhgUs95dzj0/cg5VFMAAfki44t5YFOp6nlFyMpyTKUweFBgpTpdFX5l+ RwBrJ88FmEYt3jkLwvfUpJ0WP7BFxQxl/vOYj6+cxwH5Ifp4ZAsshJ702Dc2u1+iWNYM Cd67ycsaF4N0Jia0ptQToQ9rwNxFHCPPrknoeiHa9GSFsxX+UDyPysAk/+MXK4YI7X+X z9uxX9nEsNwBO5u6oodaPgMJY4yGu4Xe4stjPV37O6oysOeil5bRPgHLwSJdhtP3KbPP Durg== MIME-Version: 1.0 X-Received: by 10.152.8.115 with SMTP id q19mr26935768laa.16.1381152969112; Mon, 07 Oct 2013 06:36:09 -0700 (PDT) Received: by 10.112.155.137 with HTTP; Mon, 7 Oct 2013 06:36:08 -0700 (PDT) In-Reply-To: <201310071252.r97Cq51N051621@mech-cluster241.men.bris.ac.uk> References: <5252A04F.1060906@passap.ru> <201310071252.r97Cq51N051621@mech-cluster241.men.bris.ac.uk> Date: Mon, 7 Oct 2013 15:36:08 +0200 Message-ID: Subject: Re: Explain staging From: Daniel Nebdal To: mexas@bris.ac.uk Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: Boris Samorodov , Ports FreeBSD X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 13:38:00 -0000 On Mon, Oct 7, 2013 at 2:52 PM, Anton Shterenlikht wrote= : > >From bsam@passap.ru Mon Oct 7 13:36:53 2013 >> >>07.10.2013 13:23, Anton Shterenlikht =D0=C9=DB=C5=D4: >> >>> What about "make fetch"? It puts files by default under >>> ports/distfiles, which, by default, is 755: >>[...] >>> What about "make extract"? Same problem: >> >>I use svn repo owned by a user for ages. When a root rights are needed, >>the ports infrastructure asks for the password. > > I've read a few books on unix security. > The typical advice is to assume the user > passwords are compromised. > If I build and install from a ports tree > owned by a user, I increase the chances of > comromising the system, if an attacker > changes some files in the ports tree, > i.e. the URL in the Makefile and the checksum > in distinfo. I'll then have to add this worry > to my already long list. > > Anton > If that happens to an account used by an admin, don't you have larger worri= es? Let's say : * You have an account with no special privileges, that you typically log in with. * That account has a ports tree * You typically install ports by compiling them as this user, then installing them with root privileges. If you use sudo, and you haven't used targetpw or something to make it ask for a different password, and you haven't set any strong limits on it, anyone that got your password would also be able to use sudo to do whatever they wanted more directly. So let's assume you're not doing that. An attacker with your password could meddle with your .profile or .cshrc or whatever, and replace your shell with a lookalike that logged all input. From there, they could get hold of whatever commands and passwords you use to install software, and reuse that to install whatever they want directly. If what you use is sudo, somehow restricted to only run make install, and only within that ports tree ... again, what would keep an attacker from just modifying any random port on the fly, installing it there and then, and then reverting the changes to reduce the risk of detection? It just seems like leaving a timebomb in the form of a modified ports directory would be a fairly inefficient thing to do if they'd already gotten that far., and it would run the risk of being overwritten and/or detected next time you updated your ports tree. Of course, if you set the ports tree a+w (or, heaven forbid, 0777), you'd be asking for trouble ... but that's not new. Then again, I might have overlooked something. :) --=20 Daniel Nebdal