Date: Mon, 03 Mar 2014 15:23:43 -0800 From: Xin Li <delphij@delphij.net> To: Kevin Oberman <rkoberman@gmail.com>, Greg Rivers <gcr+freebsd-stable@tharned.org> Cc: Mike Jakubik <mike.jakubik@intertainservices.com>, Andrey Chernov <ache@freebsd.org>, FreeBSD Stable ML <stable@freebsd.org>, des@freebsd.org Subject: Re: openssh in stable-10 broken config or sandbox Message-ID: <53150EFF.5090007@delphij.net> In-Reply-To: <CAN6yY1sm3EYW5fnzH1HbU-CzzkT7Dyr5LovaLQWWkLdMqHEn3A@mail.gmail.com> References: <531184A8.4050909@freebsd.org> <53118E9C.5030804@freebsd.org> <5314D1F9.20909@intertainservices.com> <CAN6yY1tvr7F739%2BRxiVu8MjHo399=4VPHF9zw8WWKq16bMKVcA@mail.gmail.com> <alpine.BSF.2.00.1403031430380.20838@badger.tharned.org> <CAN6yY1sm3EYW5fnzH1HbU-CzzkT7Dyr5LovaLQWWkLdMqHEn3A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/03/14 13:29, Kevin Oberman wrote: > On Mon, Mar 3, 2014 at 12:38 PM, Greg Rivers > <gcr+freebsd-stable@tharned.org >> wrote: > >> On Mon, 3 Mar 2014, Kevin Oberman wrote: >> >> On Mon, Mar 3, 2014 at 11:03 AM, Mike Jakubik < >>> mike.jakubik@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. I have just merged r261499 (pjd) as r262718 which should have fixed this issue. r261499 tests if the capability calls returned ENOSYS and silently ignores them. Note that it's generally a good idea from security prospective that one enable the new security mechanisms in their kernel, but yes, we would keep our promise on POLA on stable branches. Sorry for the breakage. Cheers, - -- Xin LI <delphij@delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTFQ7/AAoJEJW2GBstM+nsQYYP/i7teuMdm+G79dnaYFzlh3KN Ao7wiC4CUhrDUTyeMvreS+mo3lXSD/dH83eTpWUKDIEq3kHpqJ69Oi9qh01+9fSy t0lFHqKS3AqamRWoJpjygogaRAu9KpWsqQgttc7iZa+pbOeHYSiM2rmcoJauT8PX zoCi2zX3DZj2Jcm+hznvDVUFf+POpP1dBxp4u6MT8N3079nfcu5uSOPROqXodxW2 +Y71o7EQvWobsnUIhu4zK/16gWVuqmpIeGVv80uvOv935LaW1aCB30J0vZmmbbni Q59z47y/SzhtU2lOPmykj5LFpr3rlW572Wg7ibGzqksxXrqBomGmfMH78HEKKJb8 6o9kbRFH04m8TeumQ4KE7VTTc8oYa55+o5dRPCrjgkLQusfYLiZh23UZ1RmDPmZD DYhFv4nWNRkDet2o4ow5PdsSUYs/ezwfURpHTgDoUhkklr9/74F6uVYshD68Ojgs 6fALpH6T9fKES7teqalycSSNY407aGCOYQRAb+0kHVEafXKO2w4CqZ4cJ5bB8KSH tZA371LHS0n82aeBvNDzqyQBxVCJ7vZJY7jfxSRuIh1ePou7I+FduIM9i0NkhD0y 6NCNmsRgn9mt3rDCKmIdvhUc0qZH81a23q6YXkK7U+cQ26p+kksSOxM0sk/fwVBo /jj2qDuCdm9+Suj1u8Y+ =L20p -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53150EFF.5090007>