From owner-freebsd-arch@freebsd.org Tue Jul 3 16:03:41 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00BC1102CF0F for ; Tue, 3 Jul 2018 16:03:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 79A048928B for ; Tue, 3 Jul 2018 16:03:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3791E102CF04; Tue, 3 Jul 2018 16:03:40 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 129BA102CF03 for ; Tue, 3 Jul 2018 16:03:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEEA489289 for ; Tue, 3 Jul 2018 16:03:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 26DA010AFCD; Tue, 3 Jul 2018 12:03:38 -0400 (EDT) Subject: Re: What to do about rcmdsh(3) ? To: Cy Schubert , Eitan Adler References: <201807030330.w633Uchd087857@slippy.cwsent.com> Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , "O'Connor, Daniel" From: John Baldwin Message-ID: Date: Tue, 3 Jul 2018 09:03:36 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <201807030330.w633Uchd087857@slippy.cwsent.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 03 Jul 2018 12:03:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:03:41 -0000 On 7/2/18 8:30 PM, Cy Schubert wrote: > In message il.com> > , Eitan Adler writes: >> On 26 June 2018 at 23:45, O'Connor, Daniel wrote: >>> >>> >>>> On 27 Jun 2018, at 13:01, Eitan Adler wrote: >>>> >>>> On 24 June 2018 at 05:14, Konstantin Belousov wrote: >>>>> On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote: >>>>>> Now that the rcmds are removed from base, it opens a question about >>>>>> what to do with rcmdsh(3). >>>>>> This is documented as >>>>>> rcmdsh ??? return a stream to a remote command without superuser >>>>>> And is implemented as a rather simple wrapper of getaddrinfo and exec. >>>>>> >>>>>> This isn't something I'd imagine we'd add to libc now-a-days and is >>>>>> currently broken by default (due to defaulting to _PATH_RSH) >>>>>> >>>>>> I'm not sure there is much value in keeping this function around. I >>>>>> did a rather naive search for uses of this function in ports and >>>>>> couldn't find any. I'm preparing a more comprehensive patch for an >>>>>> exp-run. >>>>> There is a huge value in keeping ABI compatibility. The symbol must be k >> ept. >>>>> You may remove default version for the symbol if you are so inclined. >>>> >>>> I'm new at this. How does one do that? >>> >>> You could just leave the call, I assume it will fail with an error if rsh i >> sn't in the path. >> >> It will fail unconditionally since the call looks explicitly for >> /bin/rsh. Is it wrong to change the implementation to use PATH?I have >> not looked closely, but are there security implications to trusting >> the environment? > > If uid == 0, yes. To safely ensure that a setuid (root or otherwise) > program cannot be tricked into running some other application than > /bin/rsh, IMO the safest option might be to do what the kernel does > when executing init at boot. That is, select it from colon separated > list. We can default to /usr/local/bin/rsh with a src.conf option. > > I don't believe rcmdsh() is POSIX or SPEC 1170, so it could default to > /usr/bin/ssh instead. > > Personally, IMO, I think rcmdsh() is too much trouble for what it's > worth. It should be removed. Do we have an idea of how many > applications removing this function might impact? I'm willing to bet > very few. I think you could also just leave it as-is without changing the path and require the user to explicitly create a suitable /usr/bin/rsh if they require it for some reason. If you wanted to retire the symbol as suggested by kib@ that would also be fine and would prevent new applications from using it going forward (but you don't get to remove the source from libc). -- John Baldwin