open and euid security flaw in 5.0-Current?

[Robert Watson]

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