Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 May 2003 16:23:42 +0100
From:      "Killing" <killing@barrysworld.com>
To:        "Robert Watson" <rwatson@freebsd.org>
Cc:        freebsd-security@freebsd.org
Subject:   Re: open and euid security flaw in 5.0-Current?
Message-ID:  <006d01c31c88$4e8ae000$9f00a8c0@mshome.net>
References:  <Pine.NEB.3.96L.1030517012329.34919I-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for that Robert will do some more investigation as it does
break screen :(

    Steve /k
----- Original Message -----
From: "Robert Watson" <rwatson@freebsd.org>
To: "Killing" <killing@barrysworld.com>
Cc: <freebsd-hackers@freebsd.org>; <freebsd-security@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@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"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006d01c31c88$4e8ae000$9f00a8c0>