Partially Privileged Applications

Partially Privileged Applications

[Shahbaz Youssefi]

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. This idea requires an
improvement to the CPU architectures to allow unifying kernel and user
spaces and perform privileged instructions based on the location of
the instruction rather than a manually switched mode (or via traps).

Please, do take a look at the link. I'm far from a kernel expert so
the idea may not be as rainbows and unicorns as it seems to me right
now. But it also may be. In that case, probably we need a push by
well-known people (i.e., Linus) to get the manufacturers to implement
the feature.

At least from a developer's point of view, with this idea you could
gdb or even valgrind check the drivers in the very least with much
less chance of a kernel oops. How faster can you imagine debugging a
kernel module?

Thanks,
An unfortunate soul who has to deal with buggy kernel modules

Re: Partially Privileged Applications

[Richard Weinberger]

On Sun, Nov 10, 2013 at 4:03 PM, Shahbaz Youssefi <shabbyx@gmail.com> 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. This idea requires an
> improvement to the CPU architectures to allow unifying kernel and user
> spaces and perform privileged instructions based on the location of
> the instruction rather than a manually switched mode (or via traps).
>
> Please, do take a look at the link. I'm far from a kernel expert so
> the idea may not be as rainbows and unicorns as it seems to me right
> now. But it also may be. In that case, probably we need a push by
> well-known people (i.e., Linus) to get the manufacturers to implement
> the feature.
>
> At least from a developer's point of view, with this idea you could
> gdb or even valgrind check the drivers in the very least with much
> less chance of a kernel oops. How faster can you imagine debugging a
> kernel module?

So, we throw away 20 years of OS development and go back to hacky call
gates? ;-)

> Thanks,
> An unfortunate soul who has to deal with buggy kernel modules
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Thanks,
//richard

Re: Partially Privileged Applications

[Shahbaz Youssefi]

Not sure if I understood you (or you understood me). We don't throw
away anything. Only difference would be instead of generating a trap
to call a function in the kernel, we can just call it and have the
hardware take care of privileges. The "trap way" is the one that
actually seems hacky! A hack proposed to fix the brain-dead processors
of twenty years ago.

As a bonus you would also have more control over what parts of a
driver actually get run in privileged mode.

Care to explain why you would call this a step backwards?

On Sun, Nov 10, 2013 at 5:18 PM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> On Sun, Nov 10, 2013 at 4:03 PM, Shahbaz Youssefi <shabbyx@gmail.com> 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. This idea requires an
>> improvement to the CPU architectures to allow unifying kernel and user
>> spaces and perform privileged instructions based on the location of
>> the instruction rather than a manually switched mode (or via traps).
>>
>> Please, do take a look at the link. I'm far from a kernel expert so
>> the idea may not be as rainbows and unicorns as it seems to me right
>> now. But it also may be. In that case, probably we need a push by
>> well-known people (i.e., Linus) to get the manufacturers to implement
>> the feature.
>>
>> At least from a developer's point of view, with this idea you could
>> gdb or even valgrind check the drivers in the very least with much
>> less chance of a kernel oops. How faster can you imagine debugging a
>> kernel module?
>
> So, we throw away 20 years of OS development and go back to hacky call
> gates? ;-)
>
>> Thanks,
>> An unfortunate soul who has to deal with buggy kernel modules
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>
> --
> Thanks,
> //richard

Re: Partially Privileged Applications

[Richard Weinberger]

Am 10.11.2013 17:24, schrieb Shahbaz Youssefi:
> Not sure if I understood you (or you understood me). We don't throw
> away anything. Only difference would be instead of generating a trap
> to call a function in the kernel, we can just call it and have the
> hardware take care of privileges. The "trap way" is the one that
> actually seems hacky! A hack proposed to fix the brain-dead processors
> of twenty years ago.
> 
> As a bonus you would also have more control over what parts of a
> driver actually get run in privileged mode.
> 
> Care to explain why you would call this a step backwards?

Maybe I did not understand your idea. But to me it sounds like plain old call gates.
See: http://en.wikipedia.org/wiki/Call_gate

Thanks,
//richard

Re: Partially Privileged Applications

[Al Viro]

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.

Re: Partially Privileged Applications

[Shahbaz Youssefi]

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.

> And your driver model sounds more like a micro-kernel
> http://en.wikipedia.org/wiki/Microkernel
> In the sense that a driver is more like a privileged process.

That is true. I understood that but I thought better not mention
microkernels, just to avoid any reaction given "the history"!
I guess I would have appreciated it if Linux was a mikrokernel
or a hybrid, given how f*ing hard it is find a bug in someone else's
kernel module that just hangs the kernel.

Re: Partially Privileged Applications

[Matthias Schniedermeyer]

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

Re: Partially Privileged Applications

[Levente Kurusa]

2013-11-11 19:44 keltezéssel, Matthias Schniedermeyer írta:
> 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.

Hi,

What you describe in your blogpost already exists. It is called real-mode.
Imagine yourself as a userspace developer. You make an application and want
it to run as fast as possible and therefore you eliminate the mode-switches, which
do cost a lot of time. Your only way to stop them is by leaving out .text section
and only having the .privileged section.

Also, think about the malicious software we had back in the DOS times. You caught one,
your computer or atleast your harddrive died.

Another problem is the bad developer, they want to test out their application, but they
accidentally left out something. Just thinking about myself, I made lots of stupid mistakes
when I began development, if the CPU worked per your description, I would have bricked bunch of
computers. The whole point of separating kernelspace from userspace is not only the abstraction
of hardware, but the security as well. We want to protect the user from having the fear of bricking
his or her computer.

By this, I don't mean to say that your idea is bad, but right now we can't just trust userspace
with 'God' powers.

-- 
Regards,
Levente Kurusa

Re: Partially Privileged Applications

[Shahbaz Youssefi]

Hi,

Thanks for the feedback. You are absolutely right and as I mentioned
before, I came to realize that it would be hard to contain malicious code.

Nevertheless, honest mistakes shouldn't be a big problem. Currently,
if you write a kernel module, you can cause havoc and the only thing
preventing you from inserting a bad module is a `sudo`. For the honest
people (regardless of noob or not), it would be the same. If you want
to run a privileged application, you need a `sudo` and the implications
are as good or as bad as inserting your own kernel module.

On Tue, Nov 12, 2013 at 12:56 PM, Levente Kurusa <levex@linux.com> wrote:
> 2013-11-11 19:44 keltezéssel, Matthias Schniedermeyer írta:
>> 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.
>
> Hi,
>
> What you describe in your blogpost already exists. It is called real-mode.
> Imagine yourself as a userspace developer. You make an application and want
> it to run as fast as possible and therefore you eliminate the mode-switches, which
> do cost a lot of time. Your only way to stop them is by leaving out .text section
> and only having the .privileged section.
>
> Also, think about the malicious software we had back in the DOS times. You caught one,
> your computer or atleast your harddrive died.
>
> Another problem is the bad developer, they want to test out their application, but they
> accidentally left out something. Just thinking about myself, I made lots of stupid mistakes
> when I began development, if the CPU worked per your description, I would have bricked bunch of
> computers. The whole point of separating kernelspace from userspace is not only the abstraction
> of hardware, but the security as well. We want to protect the user from having the fear of bricking
> his or her computer.
>
> By this, I don't mean to say that your idea is bad, but right now we can't just trust userspace
> with 'God' powers.
>
> --
> Regards,
> Levente Kurusa