linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).