linux-kernel - Re: How to lock current->signal->tty

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 08 Aug 2006 13:11:54 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Eric Paris <eparis@...hat.com>, Al Viro <viro@....linux.org.uk>,
	James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	davem@...hat.com, jack@...e.cz, dwmw2@...radead.org,
	tony.luck@...el.com, jdike@...aya.com,
	James.Bottomley@...senPartnership.com
Subject: Re: How to lock current->signal->tty

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@...ho.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/