From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 22:55:52 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F0F437B401; Fri, 16 May 2003 22:55:52 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 795B843F75; Fri, 16 May 2003 22:55:51 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h4H5tWOn037680; Sat, 17 May 2003 01:55:32 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h4H5tVY1037677; Sat, 17 May 2003 01:55:32 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 17 May 2003 01:55:31 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Killing In-Reply-To: <001f01c31c1e$7e00e3d0$9f00a8c0@mshome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: freebsd-security@freebsd.org Subject: Re: open and euid security flaw in 5.0-Current? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2003 05:55:52 -0000 On Sat, 17 May 2003, Killing wrote: > On a FreeBSD 5.0 the behaviour of screen when connecting to other > users sessions have changed. Previously: > 1. login as userA start a screen as userA and disconnect > 2. login as root su - userA "screen -r" > 3. result failure as userA cant access the ttyX with such a message > Current: > 1. login as userA start a screen as userA and disconnect > 2. login as root su - userA "screen -r" > 3. result failure as userA cant access the ttyX but no message > > After looking around in screen's code I found that after doing a > seteuid( userA ) an open on root's terminal is still succeseding. > > Surely this is a problem as when running euid userA there should be no > access to ruid's files? I'm not sure this is the bug (feature?) you think it is. It sounds like you think this might be a mis-evaluation of file permissions more generally relating to saved vs. effective vs. real credentials. Based on the fact that other devfs permissions work properly, I actually don't think it's that. What you're seeing is derived from changes in the behavior of /dev as a result of devfs in 5.x. This is a result of special-case handling in devfs_access(): error = vaccess(vp->v_type, de->de_mode, de->de_uid, de->de_gid, ap->a_mode, ap->a_cred, NULL); if (!error) return (error); if (error != EACCES) return (error); /* We do, however, allow access to the controlling terminal */ if (!(ap->a_td->td_proc->p_flag & P_CONTROLT)) return (error); if (ap->a_td->td_proc->p_session->s_ttyvp == de->de_vnode) return (0); return (error); It's worth noting, though, that you can accomplish much the same thing by opening /dev/tty, which even on RELENG_4, permits you to open your own controlling terminal without going through the permission checks on the device node for the terminal itself. This reflects the fact that /dev entries are not the actual object, just references to an underlying object, and access through any of the VFS layer objects is sufficient. I'm not entirely sure this is desirable in all cases, but it's apparently not specific to FreeBSD. For example a Linux 2.2 box I have access to permits this: [rwatson@viking /dev]# su nobody bash$ cat / bash$ tty /dev/pts/0 bash$ cat /dev/pts/0 cat: /dev/pts/0: Permission denied bash$ cat /dev/tty ... So does one of Juli's Linux 2.4 boxes. So our permitting direct access to the tty via it's normal name is more liberal than is usual, but the tty access via /dev/tty is common across all platforms. We could easily fix the more liberal direct access issue by removing the code, but I'm wondering why it's there in the first place. I've CC'd Poul-Henning Kamp, author of our current devfs, to see. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories