linux-kernel - Syslets, signals, and security

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-next>] [day] [month] [year] [list]

Message-ID: <20070604163145.GA7144@c2.user-mode-linux.org>
Date:	Mon, 4 Jun 2007 12:31:45 -0400
From:	Jeff Dike <jdike@...toit.com>
To:	Zach Brown <zach.brown@...cle.com>, Ingo Molnar <mingo@...e.hu>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Syslets, signals, and security

Syslets seem like a fundamentally good idea to me, but the current
implementation, using CLONE_THREAD threads, seems like a basic
problem.

First, there are signals.  If the app has an interval timer enabled,
every thread will inherit it and you will have 32 threads getting
alarms, which seems surprising and wasteful.  I can imagine other
signals (like SIGWINCH and  SIGHUP) which might be surprising to
receive multiple times in an obstensibly single-threaded process.

Second, security.  What happens if a well-written server starts life
as root, does some (async) I/O, and setuids to a non-root uid?  There
will be a bunch of async threads still running as root, with the
result that async operations (and the main thread) will more than
occassionally regain root privs.

You can fix this by going around to all the threads in the thread
group and changing their ->uid, but that seems somewhat kludgy.  You
could also fix this by killing off the async threads on a setuid, and
make the app recreate the async threads under its new uid.  However,
the current interface has no way to give the userspace stacks back to
the process, so this would force a memory leak on the process.

There's also ptrace, which (as I think Zach already mentioned) gets
along badly with syslets.

Offhand, it seems to me that the underlying problem is that the
threads all have their own task_structs and userspaces.

If only the main thread can receive signals and exit to userspace, the
signal surprises go away.

Similarly, if they all share a task structure, the setuid problem goes
away.

There are also warts in the current interface due to all of the
threads possibly being able to return to userspace:
	they all need to be provided with userspace stacks
	they need to be given an user IP to execute
	there is a new system call for them to call when they land in
userspace.

Since the basic schedulable unit is currently a task_struct, and
syslets would prefer to have multiple schedulable units per
task_struct, this would imply some surgery on the task_struct and the
scheduler.  What I think we'd want is for the basic schedulable unit
to be not much more than a kernel stack and a register set.  A
(non-kernel-thread) task_struct would still be associated 1-1 with a
userspace, but could have multiple schedulable units, one of which is
allowed to exit to userspace.

				Jeff

-- 
Work email - jdike at linux dot intel dot com
-
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/