Date: Sun, 9 Mar 2014 14:49:14 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-10@freebsd.org, Dag-Erling SmXXrgrav <des@freebsd.org> 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... Message-ID: <alpine.BSF.2.00.1403091446330.42045@fledge.watson.org> In-Reply-To: <201403031536.33679.jhb@freebsd.org> References: <201402271729.s1RHT2rx075258@svn.freebsd.org> <201403031536.33679.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1403091446330.42045>