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?
Steve / K
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"
>
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
I'll look at screen more carfully, hopefully on monday evening. As what
its doing atm is succeding its access checks for the controlling terminal
but then failing to actually reattach. I agree that there really should be
no need for the wrapper I have which traps the screen tty dev access
error and acts on it.
Thanks for all the feedback guys.
Steve
----- Original Message -----
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To: "Robert Watson" <rwatson@freebsd.org>
Cc: "Killing" <killing@barrysworld.com>;
<freebsd-hackers@freebsd.org>;
<freebsd-security@freebsd.org>
Sent: Saturday, May 17, 2003 7:43 PM
Subject: Re: open and euid security flaw in 5.0-Current?
> In message
<Pine.NEB.3.96L.1030517102700.42953A-100000@fledge.watson.org>,
Robe> rt Watson writes:
> >
> >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 :-).
>
> This is one of those areas, where the hackish way (ie: /dev/tty)
> which something were implemented, leaves us with the problem of
> guessing what the underlying intent actually was/is.
>
> It used to be that /dev/tty had its own pseudo device driver, which
> would do weird stunts to act on the applicable real tty device driver
> for the controlling terminal of the current process.
>
> The resulting semantics of this is that a process can always open its
> controlling terminal, by opening "/dev/tty", but inconsistently,
is
> not guaranteed to be able open it by name:
>
> ssh machine -l user1
> ...
> user1% date > /dev/tty # works
> user1% date > `tty` # works
> user1% ls -l `tty`
> crw--w---- 1 user1 tty 5, 1 May 17 20:24 /dev/ttyp1
> user1% su - user2
> user2% date > /dev/tty # works
> user2% date > `tty` # doesn't work.
>
> The change I did, was to use the "on demand device creation"
feature
> of DEVFS, to make /dev/tty a sort of "variant symlink" to the
current
> process' controlling terminal device, and thereby getting rid of a
> lot of hackish code, which amongst other things, complicated locking.
>
> critter phk> ls -l /dev/tty `tty`
> crw--w---- 1 phk tty 5, 3 May 17 20:40 /dev/tty
> crw--w---- 1 phk tty 5, 3 May 17 20:40 /dev/ttyp3
>
> This means that VOP_OPEN checked against the _real_ permissions of
> the tty breaking the the following scenario:
>
> ssh machine -l user1
> ...
> user1% ls -l `tty`
> crw--w---- 1 user1 tty 5, 1 May 17 20:24 /dev/ttyp1
> user1% su - user2
> # user2 has no access to /dev/ttyp1, so /dev/tty cannot
> # be opened.
>
> Therefore, the access check was changed to always allowing the
> controlling terminal to be opened resulting in the following
> much simpler semantics:
>
> % date > /dev/tty # always works.
> % date > `tty` # always works.
>
> This IMO, reflects the intentions of the original /dev/tty, and
> since it is simpler and contains no exceptions, I also think it
> correctly reflects the "UNIX[*] philosophy" much better than
> the previous behaviour.
>
> I have no idea why or what screen(1) is doing, but from your
> description it seems to rely on the undocumented fact that in certain
> specific situations
> user2% date > `/dev/tty'
> would fail.
>
> In my eyes, that is a clear bug in screen(1).
>
> Poul-Henning
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by
incompetence.>