lkml.org 
[lkml]   [2006]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: How to lock current->signal->tty
    From
    Date
    On Tue, 2006-08-08 at 16:17 +0100, Alan Cox wrote:
    > The biggest crawly horror I've found so far in auditing the tty locking
    > is current->signal->tty. The tty layer currently and explicitly protects
    > this using tty_mutex. The core kernel likewise knows about this.
    >
    > Unfortunately:
    > SELinux doesn't do any locking at all
    > Dquot passes the tty to tty_write_message without locking
    > audit_log_exit doesn't do any locking at all
    > acct.c thinks tasklist_lock protects it (wrong)
    > drivers/char/sx misuses it unlocked in debug info
    > fs/proc/array thinks tasklist_lock will save it (also wrong)
    > fs3270 does fascinating things with it which don't look safe
    > ebtables remote debugging (#if 0 thankfully) does no locking
    > and just for fun calls the tty driver directly with no
    > driver locking either.
    > voyager_thread sets up a thread and then touches ->tty unlocked
    > (and it seems daemonize already fixed it)
    > Sparc solaris_procids sets it to NULL without locking
    > arch/ia64/kernel/unanligned seems to write to it without locking
    > arch/um/kernel/exec.c appears to believe task_lock is used
    >
    > The semantics are actually as follows
    >
    > signal->tty must not be changed without holding tty_mutex
    > signal->tty must not be used unless tty_mutex is held from before
    > reading it to completing using it
    > Simple if(signal->tty == NULL) type checks are ok
    >
    > I'm looking longer term at tty ref counting and the like but for now and
    > current distributions it might be an idea to fix the existing problems.

    Does this look sane? Or do we need a common helper factored from
    disassociate_ctty()? Why is the locking different for TIOCNOTTY in the
    non-leader case?

    ---

    selinux: fix tty locking

    Take tty_mutex when accessing ->signal->tty.
    Noted by Alan Cox.

    Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>

    ---

    security/selinux/hooks.c | 5 ++++-
    1 files changed, 4 insertions(+), 1 deletion(-)

    diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
    index 5d1b8c7..4b0f904 100644
    --- a/security/selinux/hooks.c
    +++ b/security/selinux/hooks.c
    @@ -1711,10 +1711,12 @@ static inline void flush_unauthorized_fi
    {
    struct avc_audit_data ad;
    struct file *file, *devnull = NULL;
    - struct tty_struct *tty = current->signal->tty;
    + struct tty_struct *tty;
    struct fdtable *fdt;
    long j = -1;

    + mutex_lock(&tty_mutex);
    + tty = current->signal->tty;
    if (tty) {
    file_list_lock();
    file = list_entry(tty->tty_files.next, typeof(*file), f_u.fu_list);
    @@ -1734,6 +1736,7 @@ static inline void flush_unauthorized_fi
    }
    file_list_unlock();
    }
    + mutex_unlock(&tty_mutex);

    /* Revalidate access to inherited open files. */


    --
    Stephen Smalley
    National Security Agency

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-08-08 19:13    [W:0.024 / U:2.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site