On Thu, Nov 30, 2017 at 2:23 AM, Luis R. Rodriguez wrote:
> On Mon, Nov 27, 2017 at 06:18:36PM +0100, Djalal Harouni wrote:
>> diff --git a/include/linux/module.h b/include/linux/module.h
>> index 5cbb239..c36aed8 100644
>> --- a/include/linux/module.h
>> +++ b/include/
On Tue, Nov 28, 2017 at 11:18 PM, Luis R. Rodriguez wrote:
> On Tue, Nov 28, 2017 at 10:33:27PM +0100, Djalal Harouni wrote:
>> On Tue, Nov 28, 2017 at 10:16 PM, Luis R. Rodriguez
>> wrote:
>> > On Tue, Nov 28, 2017 at 12:11:34PM -0800, Kees Cook wrote:
>> >&
On Tue, Nov 28, 2017 at 10:16 PM, Luis R. Rodriguez wrote:
> On Tue, Nov 28, 2017 at 12:11:34PM -0800, Kees Cook wrote:
>> On Tue, Nov 28, 2017 at 11:14 AM, Luis R. Rodriguez
>> wrote:
>> > kmod is just a helper to poke userpsace to load a module, that's it.
>> >
>> > The old init_module() and n
Hi Luis,
On Tue, Nov 28, 2017 at 8:14 PM, Luis R. Rodriguez wrote:
> On Mon, Nov 27, 2017 at 06:18:34PM +0100, Djalal Harouni wrote:
> ...
>
>> After a discussion with Rusty Russell [1], the suggestion was to pass
>> the capability from request_module() to security_kernel_mo
Hi Linus,
On Mon, Nov 27, 2017 at 7:44 PM, Linus Torvalds
wrote:
> On Mon, Nov 27, 2017 at 9:18 AM, Djalal Harouni wrote:
>> This uses the new request_module_cap() facility to directly propagate
>> CAP_NET_ADMIN capability and the 'netdev' module prefix to the
>>
Hi Randy,
On Mon, Nov 27, 2017 at 7:48 PM, Randy Dunlap wrote:
> Hi,
>
> Mostly typos/spellos...
>
>
> On 11/27/2017 09:18 AM, Djalal Harouni wrote:
>> Cc: Serge Hallyn
>> Cc: Andy Lutomirski
>> Suggested-by: Rusty Russell
>> Suggested-by: K
Hi Linus,
On Mon, Nov 27, 2017 at 8:12 PM, Linus Torvalds
wrote:
> On Mon, Nov 27, 2017 at 11:02 AM, Linus Torvalds
> wrote:
>>
>> Now, the above will not necessarily work with a legacy /dev/ directory
>> where al the nodes have been pre-populated, and opening the device
>> node is supposed to l
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 use task->security since
ading is
disabled forever.
[1] http://www.openwall.com/lists/oss-security/2017/02/22/3
[2] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074
[3] http://www.openwall.com/lists/oss-security/2017/03/29/2
[4] http://www.openwall.com/lists/oss-security/2017/03/07/6
[5] https://a13xp0p0v.
ed on patch by Rusty Russell and discussion with Kees Cook:
[1] https://lkml.org/lkml/2017/4/26/735
[2] https://lkml.org/lkml/2017/5/23/775
Cc: Serge Hallyn
Cc: Andy Lutomirski
Suggested-by: Rusty Russell
Suggested-by: Kees Cook
Signed-off-by: Djalal Harouni
---
include/linux/kmod.h |
patch.
Cc: James Morris
Cc: Serge Hallyn
Cc: Andy Lutomirski
Cc: Ben Hutchings
Suggested-by: Rusty Russell
Suggested-by: Kees Cook
Signed-off-by: Djalal Harouni
---
include/linux/module.h | 10 ++
include/linux/security.h | 4 +++-
kernel/module.c | 23
w.openwall.com/lists/oss-security/2017/02/22/3
[2] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074
[3] http://www.openwall.com/lists/oss-security/2017/03/29/2
[4] http://www.openwall.com/lists/oss-security/2017/03/07/6
[5] https://a13xp0p0v.github.io/2017/03/24/CVE-2017-2636.html
ns from Rusty Russel and Kees Cook [1]
[1] https://lkml.org/lkml/2017/4/26/735
Cc: Ben Hutchings
Cc: James Morris
Cc: Serge Hallyn
Cc: Solar Designer
Cc: Andy Lutomirski
Suggested-by: Rusty Russell
Suggested-by: Kees Cook
Signed-off-by: Djalal Harouni
---
net/core/dev_ioctl.c | 4 +++
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
>>
[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-
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
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 Wed, Mar 29, 2017 at 1:46 AM, Mickaël Salaün wrote:
> A landlocked process has less privileges than a non-landlocked process
> and must then be subject to additional restrictions when manipulating
> processes. To be allowed to use ptrace(2) and related syscalls on a
> target process, a landlock
On Wed, Mar 29, 2017 at 1:46 AM, Mickaël Salaün wrote:
> The seccomp(2) syscall can be used by a task to apply a Landlock rule to
> itself. As a seccomp filter, a Landlock rule is enforced for the current
> task and all its future children. A rule is immutable and a task can
> only add new restric
On Wed, Feb 22, 2017 at 2:26 AM, Mickaël Salaün wrote:
> The seccomp(2) syscall can be use to apply a Landlock rule to the
> current process. As with a seccomp filter, the Landlock rule is enforced
> for all its future children. An inherited rule tree can be updated
> (append-only) by the owner of
28 matches
Mail list logo
