From owner-freebsd-bugs@freebsd.org Thu Oct 12 17:57:39 2017 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E146E30682 for ; Thu, 12 Oct 2017 17:57:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CCBB1C3A for ; Thu, 12 Oct 2017 17:57:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v9CHvcTb055279 for ; Thu, 12 Oct 2017 17:57:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 222632] Enable Capsicum for connect(2) Date: Thu, 12 Oct 2017 17:57:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 17:57:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222632 --- Comment #12 from Ed Maste --- > There does seem to be a discrepancy across the documentation and what is > actually implemented, as CAP_CONNECT explicitly states that connect(2) is > allowed and the check is in place in the actual implementation, but conne= ct > is not present in sys/kern/capabilities.conf, resulting in ECAPMODE. Indeed, it appears there is a discrepancy between what's implemented, what = is documented, and what we believe the expected behaviour should be. Descriptions from sys/capsicum.h: /* Allows for connect(2). */ #define CAP_CONNECT CAPRIGHT(0, 0x0000000080000000ULL) /* Allows for connectat(2) on a directory descriptor. */ #define CAP_CONNECTAT (CAP_LOOKUP | 0x0000010000000000ULL) #define CAP_SOCK_CLIENT \ (CAP_CONNECT | CAP_GETPEERNAME | CAP_GETSOCKNAME | CAP_GETSOCKOPT |= \ CAP_PEELOFF | CAP_RECV | CAP_SEND | CAP_SETSOCKOPT | CAP_SHUTDOWN) And reference "Declare more capability method rights" in r224255 and "Capsi= cum overhaul" in r247602. Thus it seems the original design intent was to allow connect(2) in capabil= ity mode subject to CAP_CONNECT on the socket, but it was never added to capabilities.conf. With later refinement on thoughts on ambient authority connect() does not fit into that model and thus would not be allowed in capability mode. --=20 You are receiving this mail because: You are the assignee for the bug.=