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

From: Robert Watson (rwatson_at_freebsd.org)
Date: 05/17/03

  • Next message: Killing: "Re: su-ing error with FreeBSD 5.0"
    Date: Sat, 17 May 2003 01:55:31 -0400 (EDT)
    To: Killing <killing@barrysworld.com>
    
    

    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-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"


  • Next message: Killing: "Re: su-ing error with FreeBSD 5.0"

    Relevant Pages

    • Re: open and euid security flaw in 5.0-Current?
      ... login as userA start a screen as userA and disconnect ... the fact that other devfs permissions work properly, ... bash$ cat / ... bash$ cat /dev/pts/0 ...
      (freebsd-hackers)
    • Re: "Send as" works incorrectly
      ... > Boris Lokhvitsky wrote: ... >> mailbox access rights to UserA. ... >> It works fine if UserA is member of Exchange administrators group ... Apparently, something with permissions disappearing. ...
      (microsoft.public.exchange.admin)
    • Re: Prevent posting on behalf of other users on Public folders
      ... UserA is not allowed access to UserB's mailbox, ... I've looked in all the properties of the Public folder, ... monkeying around with permissions in ESM). ...
      (microsoft.public.exchange.admin)
    • Re: "Send as" works incorrectly
      ... This cache contains information including permissions and the ... Microsoft Exchange Support ... >> Two users - UserA and UserB. ... UserB account is disabled. ...
      (microsoft.public.exchange.admin)
    • EnableDisable Trigger
      ... UserA has db_owner permissions to a database in test. ... UserA also has 'Alter Any Database DDL Trigger' permission. ...
      (microsoft.public.sqlserver.security)