Re: open and euid security flaw in 5.0-Current?

• Previous message: Killing: "open and euid security flaw in 5.0-Current?"
• Maybe in reply to: Killing: "open and euid security flaw in 5.0-Current?"
• Next in thread: Killing: "Re: open and euid security flaw in 5.0-Current?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: "Robert Watson" <rwatson@freebsd.org>
Date: Sat, 17 May 2003 16:23:42 +0100

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"
>

_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

• Previous message: Killing: "open and euid security flaw in 5.0-Current?"
• Maybe in reply to: Killing: "open and euid security flaw in 5.0-Current?"
• Next in thread: Killing: "Re: open and euid security flaw in 5.0-Current?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]