Hi Kees,
On Thu, Jun 1, 2017 at 9:10 PM, Kees Cook wrote:
> On Thu, Jun 1, 2017 at 7:56 AM, Djalal Harouni wrote:
...
>
>> BTW Kees, also in next version I won't remove the
>> capable(CAP_NET_ADMIN) check from [1]
>> even if there is the new request_module_cap(),
On Tue, May 30, 2017 at 7:59 PM, Kees Cook wrote:
[...]
>>> I see a few options:
>>>
>>> 1) keep what you have for v4, and hope other places don't use
>>> __request_module. (I'm not a fan of this.)
>>
>> Yes even if it is documented I wouldn't bet on it, though. :-)
>
> Okay, we seem to agree: we'
On Tue, May 23, 2017 at 9:48 AM, Solar Designer wrote:
>> >>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer
>> >>> wrote:
>> >>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote:
>> >>> >> *) When module
On Tue, May 23, 2017 at 9:19 PM, Kees Cook wrote:
> On Tue, May 23, 2017 at 3:29 AM, Djalal Harouni wrote:
[...]
>> I think if there is an interface request_module_capable() , then code
>> will use it. The DCCP code path did not check capabilities at all and
>> called re
On Tue, May 23, 2017 at 1:38 AM, Andy Lutomirski wrote:
> On Mon, May 22, 2017 at 4:07 PM, Kees Cook wrote:
>> On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni wrote:
>>> On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote:
>>>> On Mon, May 22, 2017 at 03:49:15
On Tue, May 23, 2017 at 12:20 AM, Kees Cook wrote:
> On Mon, May 22, 2017 at 4:57 AM, Djalal Harouni wrote:
>> This is a preparation patch for the module auto-load restriction feature.
>>
>> In order to restrict module auto-load operations we need to check if the
>>
On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote:
> On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote:
>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote:
>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote:
>> >> *) When modu
Hi Alexander,
On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote:
> Hi Djalal,
>
> Thank you for your work on this!
>
> On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote:
>> *) When modules_autoload_mode is set to (2), automatic module loading is
>>
Suggested-by: Kees Cook
*) Improved documentation.
*) Removed unused code.
# Changes since v1:
*) Renamed module to ModAutoRestrict
*) Improved documentation to explicity refer to module autoloading.
*) Switched to use the new task_security_alloc() hook.
*) Switched from rhash tables to u
[1] http://www.openwall.com/lists/oss-security/2017/02/22/3
[2] http://www.openwall.com/lists/oss-security/2017/03/29/2
[3] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074
Cc: Ben Hutchings
Cc: Rusty Russell
Cc: James Morris
Cc: Serge Hallyn
Cc: Andy Lutomirski
Suggested-
sandboxed apps or containers will be
restricted to trigger automatic module loading, other parts of the
system can continue to use the system as it is which is the case of the
desktop.
[1] http://www.openwall.com/lists/oss-security/2017/02/22/3
[2] http://www.openwall.com/lists/oss-security
equest() hook.
Based on patch by Rusty Russell:
https://lkml.org/lkml/2017/4/26/735
Cc: Serge Hallyn
Cc: Andy Lutomirski
Suggested-by: Rusty Russell
Suggested-by: Kees Cook
Signed-off-by: Djalal Harouni
[1] https://lkml.org/lkml/2017/4/24/7
---
include/linux/kmod.h | 15 --
On Fri, Jun 24, 2016 at 6:15 AM, Andy Lutomirski wrote:
> On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen wrote:
>> On 06/23/16 23:46, Andrew Morton wrote:
>>> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen
>>> wrote:
>>>
There are many basic ways to control processes, including capabil
13 matches
Mail list logo
