From owner-svn-src-all@FreeBSD.ORG Sun Mar 9 14:49:16 2014 Return-Path: Delivered-To: svn-src-all@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 31B65FA7; Sun, 9 Mar 2014 14:49:16 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 09E17A8; Sun, 9 Mar 2014 14:49:16 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id A6AAE46B0D; Sun, 9 Mar 2014 10:49:15 -0400 (EDT) Date: Sun, 9 Mar 2014 14:49:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin Subject: Re: svn commit: r262566 - in stable/10: crypto/openssh crypto/openssh/contrib/caldera crypto/openssh/contrib/cygwin crypto/openssh/contrib/redhat crypto/openssh/contrib/suse crypto/openssh/openbsd-comp... In-Reply-To: <201403031536.33679.jhb@freebsd.org> Message-ID: References: <201402271729.s1RHT2rx075258@svn.freebsd.org> <201403031536.33679.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-10@freebsd.org, Dag-Erling SmXXrgrav X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 14:49:16 -0000 On Mon, 3 Mar 2014, John Baldwin wrote: >> Log: >> MFH (r261320): upgrade openssh to 6.5p1 >> MFH (r261340): enable sandboxing by default > > Mails on stable@ suggest that this latter change may be a bit of a POLA > violation as if people are using a custom kernel configuration that doesn't > include CAPSICUM they are now locked out of their boxes as sshd fails. It > seems that this is at least worth a note in UPDATING if not adding a > workaround to handle the case of a kernel without CAPSICUM. Most userspace tools that support Capsicum will explicitly test for a kernel generating ENOSYS due to non-support and 'fail open' by not using sandboxing. That strategy becomes more complex as applications become more complex, and in the long term we'll want to move away from conditional support. In the mean time, I'd generally recommend that any code being used on 9.x support runtime detection of Capsicum -- either via feature_is_present(3) or ENOSYS back from cap_enter(). The ugly bit is whether or not to use other sandboxing techniques (e.g., chroot()) if Capsicum can't be found, since that stuff tends to be pretty messy. Robert