Date: Tue, 24 Nov 2015 17:33:08 -0500 From: Rich Felker <dalias@...c.org> To: kernel-hardening@...ts.openwall.com Subject: Re: System call interface changes On Tue, Nov 24, 2015 at 09:54:27PM +0100, Florian Weimer wrote: > On 11/24/2015 09:10 PM, Kees Cook wrote: > > > Ah, are you looking at this as an anti-ROP idea? What's the bug class > > or exploitation method you're looking at addressing? > > The idea, as it has been presented to me, is to remove the ability to > invoke execve (and a few other system calls) completely, to push > attackers *towards* ROP as the only means for injecting code into a > process (not all processes, obviously, but a large class of processes as > feasible). > > As far as I know, this is intended as a post-exploitation mitigation > (before policy-based mechanisms or containers kick in). I don't know > enough about real-world attack scenarios to tell if these changes would > make a difference. If the intent is only to block a single syscall, why would you break the existing user-kernel interface boundary and require a new alternate one rather than just doing something like seccomp/pledge/prctl to disable exec* syscalls and whatever else needs to be blocked? I'm also a bit confused how you would take advantage of this without static linking since libc.so will contain all the syscalls and syscall(). Rich
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.