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...

[Robert Watson]

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