open and euid security flaw in 5.0-Current?

[Robert Watson]

On Sat, 17 May 2003, Killing wrote:

> Thanks for that Robert will do some more investigation as it does break
> screen :(

Try replacing the devfs_access() contents with solely a call to:

	return (vaccess(vp->v_type, de->de_mode, de->de_uid, de->de_gid,
	    ap->a_mode ,ap->a_cred, NULL));

This should restore the traditional access controls for the controlling
terminal.  Again, I'm not sure what the rationale is for the  new access
controls, and want to find out before we make any changes to the base
system, but it does strike me that screen breaking is gratuitous :-).

> 
>     Steve /k
> ----- Original Message -----
> From: "Robert Watson" <rwatson at freebsd.org>
> To: "Killing" <killing at barrysworld.com>
> Cc: <freebsd-hackers at freebsd.org>; <freebsd-security at freebsd.org>
> 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 at 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 at fledge.watson.org      Network Associates Laboratories
> >
> >
> >
> > _______________________________________________
> > freebsd-hackers at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> >
> 
>