From owner-freebsd-hackers@FreeBSD.ORG Sat May 17 07:24:38 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 653C937B401; Sat, 17 May 2003 07:24:38 -0700 (PDT) Received: from smtp-relay1.barrysworld.com (ns1.barrysworld.com [213.221.172.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id D26E743F3F; Sat, 17 May 2003 07:24:36 -0700 (PDT) (envelope-from killing@barrysworld.com) Received: from [213.221.181.50] (helo=barrysworld.com) by smtp-relay1.barrysworld.com with esmtp (Exim 4.12) id 19H2br-00052o-00; Sat, 17 May 2003 15:24:27 +0100 Received: from gromit [212.211.96.14] by barrysworld.com with ESMTP (SMTPD32-7.15) id A6C04FF00288; Sat, 17 May 2003 15:27:12 +0100 Message-ID: <006d01c31c88$4e8ae000$9f00a8c0@mshome.net> From: "Killing" To: "Robert Watson" References: Date: Sat, 17 May 2003 16:23:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 14:24:38 -0000 Thanks for that Robert will do some more investigation as it does break screen :( Steve /k ----- Original Message ----- From: "Robert Watson" To: "Killing" Cc: ; Sent: Saturday, May 17, 2003 6:55 AM Subject: Re: open and euid security flaw in 5.0-Current? > 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 > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >