From: Oleg Nesterov <oleg@redhat.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Hugh Dickins <hugh@veritas.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Joe Malicki <jmalicki@metacarta.com>,
Michael Itz <mitz@metacarta.com>,
Kenneth Baker <bakerk@metacarta.com>,
Chris Wright <chrisw@sous-sol.org>,
David Howells <dhowells@redhat.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Greg Kroah-Hartman <gregkh@suse.de>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Q: check_unsafe_exec() races (Was: [PATCH 2/4] fix setuid sometimes doesn't)
Date: Sun, 29 Mar 2009 23:36:35 +0200 [thread overview]
Message-ID: <20090329213635.GA21820@redhat.com> (raw)
In-Reply-To: <20090329060118.GI28946@ZenIV.linux.org.uk>
On 03/29, Al Viro wrote:
>
> > In principle, we can mark these threads as "-EAGAIN on such clone()" and
> > clean that on exec failure.
We can't. We can miss the new subthread if we race with clone(CLONE_THREAD).
Unless we add the additional locking, of course.
We can set current->signal->flags |= SIGNAL_DO_NOT_CLONE_FS. But this is
really nasty. For examlpe, what if this flag is already set when
check_unsafe_exec() takes ->siglock ? We should return -ESOMETHING, not
good. Or schedule_timeout_uninterruptible(1) until it is cleared?
This also means copy_process()->copy_fs() path should take ->siglock too,
otherwise we we don't have a barrier.
> ... or just do that to fs_struct. After finding that there's no outside
> users. Commenst?
This is even worse. Not only we race with our sub-threads, we race
with CLONE_FS processes.
We can't mark fs_struct after finding that there's no outside users
lockless. Because we can't know whether this is "after" or not, we
can't trust "atomic_read(fs->count) <= n_fs".
Unless we re-use fs_struct->lock. In this case copy_fs() should take
it too. But again, ->fs can be already marked when we enter
check_unsafe_exec().
And btw check_unsafe_exec() seem to have another hole. Another thread
(which shares ->fs with us) can do exit_fs() right before we read
fs->count. Since this thread was already accounted in n_fs, we can
miss the fact we share ->fs with another process.
Perhaps I missed something...
Not that I like this idea (actually I hate), but perhaps we can change
the meaning of LSM_UNSAFE_SHARE,
selinux_bprm_set_creds:
if (new_tsec->sid != old_tsec->sid) {
...
if (avc_has_perm(...))
bprm->unsafe |= LSM_UNSAFE_SHARE;
}
Then we modify de_thread(). It sends SIGKILL to all subthreads, this
means that another thread can't clone() after we drop ->siglock. So we
can add this code to the ->siglock protected section
if (unlikely(bprm->unsafe & LSM_UNSAFE_SHARE)) {
if (fs_struct_is_shared())
return -EPERM;
}
...
zap_other_threads();
Oh, ugly.
I'd better hope I missed something ;)
Oleg.
next prev parent reply other threads:[~2009-03-29 21:42 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-28 23:16 [PATCH 1/4] compat_do_execve should unshare_files Hugh Dickins
2009-03-28 23:20 ` [PATCH 2/4] fix setuid sometimes doesn't Hugh Dickins
2009-03-29 0:53 ` Q: check_unsafe_exec() races (Was: [PATCH 2/4] fix setuid sometimes doesn't) Oleg Nesterov
2009-03-29 4:10 ` Al Viro
2009-03-29 4:14 ` Al Viro
2009-03-29 4:52 ` Oleg Nesterov
2009-03-29 5:55 ` Al Viro
2009-03-29 6:01 ` Al Viro
2009-03-29 21:36 ` Oleg Nesterov [this message]
2009-03-29 22:20 ` Al Viro
2009-03-29 23:56 ` Oleg Nesterov
2009-03-30 0:03 ` Oleg Nesterov
2009-03-30 1:08 ` Al Viro
2009-03-30 1:13 ` Al Viro
2009-03-30 1:36 ` Oleg Nesterov
2009-03-30 1:40 ` Oleg Nesterov
2009-03-30 12:31 ` Al Viro
2009-03-30 14:32 ` Hugh Dickins
2009-03-31 6:16 ` Al Viro
2009-04-01 0:28 ` Hugh Dickins
2009-04-01 2:38 ` Al Viro
2009-04-01 3:03 ` Al Viro
2009-04-01 11:25 ` Hugh Dickins
2009-04-06 15:31 ` Oleg Nesterov
2009-04-19 16:30 ` Hugh Dickins
2009-04-21 16:10 ` Oleg Nesterov
2009-04-21 16:31 ` Linus Torvalds
2009-04-21 17:15 ` Oleg Nesterov
2009-04-21 17:35 ` Linus Torvalds
2009-04-21 19:39 ` Hugh Dickins
2009-04-23 23:01 ` [PATCH 1/2] do_execve() must not clear fs->in_exec if it was set by another thread Oleg Nesterov
2009-04-23 23:18 ` Roland McGrath
2009-04-23 23:31 ` Al Viro
2009-04-24 11:57 ` [PATCH 3/2] check_unsafe_exec: rcu_read_unlock Hugh Dickins
2009-04-24 14:34 ` Oleg Nesterov
2009-04-24 4:20 ` [PATCH 1/2] do_execve() must not clear fs->in_exec if it was set by another thread Hugh Dickins
2009-04-23 23:02 ` [PATCH 2/2] check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/ Oleg Nesterov
2009-04-23 23:18 ` Roland McGrath
2009-04-24 4:29 ` Hugh Dickins
2009-04-01 11:18 ` Q: check_unsafe_exec() races (Was: [PATCH 2/4] fix setuid sometimes doesn't) Hugh Dickins
2009-04-06 15:51 ` Oleg Nesterov
2009-04-19 16:44 ` Hugh Dickins
2009-04-21 16:39 ` Oleg Nesterov
2009-03-30 23:45 ` Serge E. Hallyn
2009-03-31 6:19 ` Al Viro
2009-03-28 23:21 ` [PATCH 3/4] fix setuid sometimes wouldn't Hugh Dickins
2009-03-29 11:19 ` Alexey Dobriyan
2009-03-29 21:48 ` Oleg Nesterov
2009-03-29 22:37 ` Al Viro
2009-03-28 23:23 ` [PATCH 4/4] Annotate struct fs_struct's usage count restriction Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090329213635.GA21820@redhat.com \
--to=oleg@redhat.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bakerk@metacarta.com \
--cc=chrisw@sous-sol.org \
--cc=dhowells@redhat.com \
--cc=gregkh@suse.de \
--cc=hugh@veritas.com \
--cc=jmalicki@metacarta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mitz@metacarta.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.