Date: Sat, 02 Sep 2000 16:29:35 -0600 From: Warner Losh <imp@village.org> To: Peter Wemm <peter@netplex.com.au> Cc: arch@FreeBSD.ORG Subject: Re: setuid ssh should die (Re: Request for review: nsswitch) Message-ID: <200009022229.e82MTZG02428@billy-club.village.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009022229.e82MTZG02428>