From: Al Viro <viro@ZenIV.linux.org.uk>
To: Shahbaz Youssefi <shabbyx@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Partially Privileged Applications
Date: Mon, 11 Nov 2013 00:43:09 +0000 [thread overview]
Message-ID: <20131111004309.GU13318@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CALeOzZ_K0o_h4gJ4w-twL5=-0QjC1XWb=m948wXWwjndr4q_Kw@mail.gmail.com>
On Sun, Nov 10, 2013 at 04:03:36PM +0100, Shahbaz Youssefi wrote:
> Dear all,
>
> First, please CC replies to myself. Second, this is an RFC.
>
> I've been tampering with an idea for some time now and I've done some
> research. Finally, I wrote it down here (a terrible place as it turned
> out):
>
> http://shahbaz-youssefi.blogspot.it/2013/11/partially-privileged-applications.html
>
> and would like to know what you think.
That it's javashit-infested and bloody hard to read without the damn thing,
for starters...
You *can't* allow userland to call an arbitrary kernel function with
arbitrary arguments. Consider e.g. a syscall that validates the
arguments and, if they are OK, calls a function that sends given
signal to given process. Allow to call that function directly and
you've got a nice, shiny roothole. The same goes for anything that
modifies kernel data structures - you either have to keep validating the
arguments again and again on each function call (which will cost *much*
more than what we currently have and will depend on being unable to
call the address other than the entry point and skip the validation) or
you lose all protection of kernel data structures, with obvious nasty
results. And that is not to mention the lovely issues with stack
switching (you really don't want to see what happens if stack page
gets swapped out under you in the kernel), the fun with being able to
call a function without locks it expects grabbed by callers, etc.
You can define a bunch of "safe to call" addresses. You will have to
do stack switching, arguments validation, etc. on each of them and it
won't be any prettier than what we do on syscall entry. That's what
the call gates are; it had been tried, the machinery is still there
on x86 and nobody sane uses it for a lot of very good reasons.
Again, flat "allow function call to any address with any arguments and
any stack pointer value" is a non-starter - you have shared data structures
to deal with, quite a few of those being security sensitive and the thing
you seem to be suggesting will fuck up immediately under such conditions.
next prev parent reply other threads:[~2013-11-11 0:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-10 15:03 Partially Privileged Applications Shahbaz Youssefi
2013-11-10 16:18 ` Richard Weinberger
2013-11-10 16:24 ` Shahbaz Youssefi
2013-11-10 16:44 ` Richard Weinberger
2013-11-11 0:43 ` Al Viro [this message]
[not found] ` <20131110190633.GA18073@citd.de>
2013-11-11 13:05 ` Shahbaz Youssefi
2013-11-11 18:44 ` Matthias Schniedermeyer
2013-11-12 11:56 ` Levente Kurusa
2013-11-12 12:20 ` Shahbaz Youssefi
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=20131111004309.GU13318@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=shabbyx@gmail.com \
/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.