openssh in stable-10 broken config or sandbox

[Kevin Oberman]

On Mon, Mar 3, 2014 at 12:38 PM, Greg Rivers <gcr+freebsd-stable at tharned.org
> wrote:

> On Mon, 3 Mar 2014, Kevin Oberman wrote:
>
>  On Mon, Mar 3, 2014 at 11:03 AM, Mike Jakubik <
>> mike.jakubik at intertainservices.com> wrote:
>>
>>  On 03/01/14 02:39, Andrey Chernov wrote:
>>>
>>>  On 01.03.2014 10:56, Andrey Chernov wrote:
>>>>
>>>>  Hi.
>>>>> Default /etc/ssh/sshd_config have
>>>>> #UsePrivilegeSeparation sandbox
>>>>> I.e. 'sandbox' by default. It breaks logins with error:
>>>>> sshd[81721]: fatal: ssh_sandbox_child: failed to limit the network
>>>>> socket [preauth]
>>>>> Fixed by using old way, i.e. direct
>>>>> UsePrivilegeSeparation yes
>>>>> instead of 'sandbox'. Please fix this bug.
>>>>>
>>>>>  Just find that capsicum is required now for default (i.e. sandbox)
>>>> mode.
>>>> Don't think it is wise move, people may lost remote connections that
>>>> way, at least UPDATING entry is needed, but check for WITHOUT_CAPSICUM
>>>> for defaults will be better.
>>>>
>>>>
>>>>  Personally I find this to be a monumental screw up, such a drastic
>>> change
>>> and not even so much as an entry in UPDATING, what ever happened to POLA?
>>>
>>>
>> +1
>>
>> I didn't get bitten by this by the good fortune of seeing the first
>> message
>> on this issue just minutes after I updated my system. Saw the change in
>> mergemaster, so immediately edited the installed file back to "yes".  But,
>> if this had been a remote server, I would have been in deep weeds. This is
>> simply not acceptable practice!
>>
>>
> Not to disagree, but I think we should tone down the flogging of a person
> who's working hard to make FreeBSD better.  I'm sure this wasn't
> intentional, and the change probably passed all of his tests.  If this were
> -RELEASE, I might feel differently, but it is -STABLE after all.  I do
> certainly agree that an UPDATING entry would have been warranted.
>
> --
> Greg
>

It was clearly intentional as it was specifically mentioned in the commit
message.

Oversights happen and I don't have a problem with that. If DES just didn't
think about the fact that it would break sshd if capsicum was not
available, that happens. I've made bigger mistakes, probably this week. The
problem is that the change was not rolled back and no entry was made to
UPDATING.

It's been over 4 days and, even if DES is tied up and has not seen the
issue, someone should have added t note to UPDATING so people have some
warning that sshd will break in most cases if they just accept the change
to sshd.conf. (Yes, it is not obvious who should have done this, but lots
of folks have access to update UPDATING.) Lots of folks use STABLE in
production. It's not HEAD and every effort is supposed to be made to not
break things, or at least warn people if something will break running
systems.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com