From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 22:00:16 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 520AFDEA for ; Mon, 8 Sep 2014 22:00:16 +0000 (UTC) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C87671364 for ; Mon, 8 Sep 2014 22:00:15 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id p9so6855190lbv.14 for ; Mon, 08 Sep 2014 15:00:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=acFEZbNPLuwSnOHeMdXHr179bSYY0+PA+BJi8KElmaU=; b=dz7yioftksLUccjymM+E3nUvxwkBskkCoBJ8vjgLnkO4SqRvhlU5anoiuCP2aWBGOV mYLxctr39LOX9S5JLL1z70t2hqornl58JxoHZhHVfXOr2OD4JawN7cq9njhdHn/tJ6c1 SPDFdVmzdyBFgwgmef4zYDlGHCdAqG5AQIg/BYrh9uRWJMLlqCg48j5xRyVaYIJuMXLk KBtDwXV1uRwkkggOkITJm6LCxb5F7qf12lIcr5Uj5yndzb5pOKCISUDAHchMWBSYKmPs 6V4DfVRdiiZBHtRR51JEfXjy6n9db+rvgvoocutPdnhPed7Z57eLVdwWLOwtQC/ljbGQ K1fQ== X-Gm-Message-State: ALoCoQkQtimLt9vchbaPWygM4o8H7UYqxXUJlTZwJeAb6PJA3n+kVa0wGIYySNqSkWy0/aqWZQ0R X-Received: by 10.152.21.42 with SMTP id s10mr32190277lae.61.1410213607613; Mon, 08 Sep 2014 15:00:07 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id os7sm3909007lbb.42.2014.09.08.15.00.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Sep 2014 15:00:07 -0700 (PDT) Message-ID: <540E26E6.5070700@freebsd.org> Date: Tue, 09 Sep 2014 02:00:06 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Patrick Kelsey Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient References: <540E14C4.9080201@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 22:00:16 -0000 On 09.09.2014 1:13, Patrick Kelsey wrote: > You make a godo point about the wider use of fcntl() in libc - aside > from the rpc code, by my count there are 14 other entry points in libc > that use fcntl in their implementation. To experience breakage, > programs that use those entry points would also have to be supplying > them fds with restricted rights that do not include CAP_FCNTL. By my > count, there are currently only 12 programs in -current that call > cap_rights_limit(). I don't think these counts inform us very well as > to the presence and extent of any capsicum+libc issues similar to the > one that I've raised. Those 12 programs mentioned above would have to > be audited to determine if any of the 15 libc entry points (including > fcntl) that use fcntl are being used on those restricted fds without > being granted CAP_FCNTL rights, and whether there are overt or potential > failures occurring as a result. Consider that the failure mode in > tcpdump that I found requires that you be using multiple capture files > with size-based rotation, otherwise all works fine. Also consider that > the failure mode in dhclient only occurs when a rewritten client lease > file is smaller than its predecessor. Just to note by quick glance: tcpdump use fdopen(), so in some cases probably already broken without F_GETFL rights. openssh use fdopen(), so suspicious about F_GETFL too, but I don't traverse the order in which fdopen() and cap_rights_* there are applied. > I don't think that this read-only fcntl(F_GETFL) which doesn not modify > anything deserves any special rights at all (i.e. can be just enabled by > default in contrast to F_SETFL), but I am not capsicum expert. > > I don't think I am in a position to comment on the implications of > permanent F_GETFL rights either. I do think that the point about wider > use of fcntl(F_GETFL) in libc does argue against making a CAP_FSEEK > right in sys/capability.h, as it would appear users of capsicum and libc > are more in need of a map of capsicum rights required by libc entry > points than they are of convenience #defines. Theoretically it will be possible to get rid of fcntl(F_GETFL) in fseek(), but O_APPEND flag need to be stored somewhere in that case, and stdio _flags already have all bit occupied for 16bit short. So the price will be changing size of the main stdio structure __sFILE to add new space for flags, which is undesirable I think. -- http://ache.vniz.net/