linux-kernel - Re: Partially Privileged Applications

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALeOzZ-oG9zfi-uM5FtLVnLXEs3DgW6Sz4SCMsM_tnkqs348UQ@mail.gmail.com>
Date:	Tue, 12 Nov 2013 13:20:29 +0100
From:	Shahbaz Youssefi <shabbyx@...il.com>
To:	levex@...ux.com
Cc:	Matthias Schniedermeyer <ms@...d.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Partially Privileged Applications

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@...ux.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@...d.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/