From owner-freebsd-arch Sat Sep 2 15:29:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0B68237B422 for ; Sat, 2 Sep 2000 15:29:50 -0700 (PDT) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA15229; Sat, 2 Sep 2000 16:29:48 -0600 (MDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.0/8.8.3) with ESMTP id e82MTZG02428; Sat, 2 Sep 2000 16:29:35 -0600 (MDT) Message-Id: <200009022229.e82MTZG02428@billy-club.village.org> To: Peter Wemm Subject: Re: setuid ssh should die (Re: Request for review: nsswitch) Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Sat, 02 Sep 2000 15:07:08 PDT." <200009022207.e82M78G32995@netplex.com.au> References: <200009022207.e82M78G32995@netplex.com.au> Date: Sat, 02 Sep 2000 16:29:35 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200009022207.e82M78G32995@netplex.com.au> Peter Wemm writes: : Perhaps we can add a clearsetugid() syscall that apps can call when they : are prepared to guarantee that things like libc getpwent() don't have a : cached copy of the priviliged master.passwd in memory that a coredump might : otherwise expose or ptrace() could extract. No. clearsetugid is a *BAD* *BAD* idea. Unless it also makes it impossible to set ones uid further after it is called. : On the other hand, I don't think applications *can* make this guarantee - : they have no way to be *certain* that libc hasn't cached something : sensitive. Exactly. There are other reasons for issetugid() than just core dumps. It also protects many variables from being looked at to get at files that otherwise couldn't be got at. The particular case that we're talking about might be best handled by dropping privs for the open and then getting them back, but I seem to recall there was a problem with this. I have an open + fstat implementation that works, but causes the open routine of drivers to be called (as well as the close), which can cause problems for people with tape drives on their systems (which is why I haven't committed it yet). Access(2) introduces a race between when it is checked and when it is opened, which is not good. doing a euid = geteuid(); seteuid(getuid()); open(...); seteuid(euid); might work, but I seem to recall not doing that because of some pathological, but important case that someone brough up in the code review. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message