[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5665B344.6030706@gmail.com>
Date: Mon, 7 Dec 2015 17:26:44 +0100
From: lazytyped <lazytyped@...il.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: System call interface changes
On 12/7/15 4:44 PM, Florian Weimer wrote:
> On 11/24/2015 10:43 PM, Kees Cook wrote:
>
>> Cool. Well, we can certainly look at existing public exploits and
>> PoCs. That's what I've been trying to collect on the Kernel
>> Self-Protection Project wiki pages. There are plenty of things we
>> could add to that list from the ROP world. Maybe it'd be good to look
>> through various exploit lists to find stuff that use techniques that
>> are either missing from the wiki page or are better examples? Do you
>> (or someone else) have time to go on a research/collection exercise?
> The proposal I have (and which prompted the question about the system
> call interface) is to block execve because many proof-of-concept exploit
> use execve or system to spawn a shell or run arbitrary commands.
So just drop that privilege? Pretty much any operating system implements
a form of sandboxing/privilege/capability filtering. It's, of course,
application specific.
Keep in mind that blocking execve leaves open chown(), chmod(), mount()
and a large number of other system calls that can be leveraged to
achieve a similar result.
- twiz
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
