From: Matthias Schniedermeyer <ms@citd.de>
To: Shahbaz Youssefi <shabbyx@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Partially Privileged Applications
Date: Mon, 11 Nov 2013 19:44:47 +0100 [thread overview]
Message-ID: <20131111184447.GA24530@citd.de> (raw)
In-Reply-To: <CALeOzZ_TpR7UxevNZET=ZFu8qL=646pWDwebNT6FH5Jvhv4-GA@mail.gmail.com>
On 11.11.2013 14:05, Shahbaz Youssefi wrote:
> On Sun, Nov 10, 2013 at 8:06 PM, Matthias Schniedermeyer <ms@citd.de> wrote:
> > I don't see a way around "borders" (Papers please), otherwise you can't
> > reject things you don't want, you have to check if that something that
> > is to be done is allowed. For e.g. you would get around every
> > permission-check, because the code you called is allowed to do
> > everything.
>
> You're right actually. Proper linking solves the issue for "good people",
> but I can't think of a not-dirty way for preventing bad calls from
> "bad people". I may get back here if I do find a solution.
After thinking a bit about this.
It depends on the samantics of when the processor switches privileges.
IF the processor only ever switches privileges for jmp/call/ret(...) you
could place a privileged page with nothing but NOPs before the function
that you actually want to call with elevated privileges, but whose page
is NOT marked as privileged.
You then call/jump to the last NOP and let the CPU "slide" over into the
next page. This way you could be sure that the necessary check-part of
the function can't be circumvented and still have the higher privileges.
But then what about functions the function might have to call, they
would need to be in a privileged page or you would need a "keep
privileges, regardless of page attribute" jmp/call. In the case of that
functions being in a privileged page, you would have to make sure that
you can't call them directly as "bad people" would just do that.
You would then need this kind auf NOP-Page before each function you want
to be able to call, which wastes a certain amount of memory and also
forces you to align each function to the beginning of a page (which also
wastes memory). But what is a megabyte or so of wasted memory with
gigabytes of memory. :-)
But essentially it would still be similar to the mentioned call gates.
All in all it still sounds like a nightmare to "get right".
--
Matthias
next prev parent reply other threads:[~2013-11-11 18:45 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
[not found] ` <20131110190633.GA18073@citd.de>
2013-11-11 13:05 ` Shahbaz Youssefi
2013-11-11 18:44 ` Matthias Schniedermeyer [this message]
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=20131111184447.GA24530@citd.de \
--to=ms@citd.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).