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 modules_autoload_mode is set to (2), automatic module loading
>> >>> >> is
>> >>
On Tue, May 23, 2017 at 11:36 AM, Kees Cook wrote:
> On Tue, May 23, 2017 at 12:48 AM, Solar Designer wrote:
>> For modules_autoload_mode=2, we already seem to have the equivalent of
>> modprobe=/bin/true (or does it differ subtly, maybe in return values?),
>> which I already use at startup on a
On Tue, May 23, 2017 at 12:48 AM, Solar Designer wrote:
> For modules_autoload_mode=2, we already seem to have the equivalent of
> modprobe=/bin/true (or does it differ subtly, maybe in return values?),
> which I already use at startup on a GPU box like this (preloading
> modules so that the OpenC
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: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 modules_autoload_mode is set to (2), automatic module loading
> >>> >> is
> >>> >> disabled for all. Once set, this value can not be changed
On Mon, May 22, 2017 at 4:38 PM, Andy Lutomirski wrote:
> I think that having the un-resettable mode is unnecessary. We should
> have option that disables loading modules entirely and cannot be
> unset. (That means no explicit loads and not implicit loads.) Maybe
> we already have this. Otherw
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:15PM +0200, Djalal Harouni wrote:
On Mon, May 22, 2017 at 2:08 PM, Solar Designer 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: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 Ha
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 modules_autoload_mode is set to (2)
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 modules_autoload_mode is set to (2), automatic module loading is
> >> disabled for all. Once set
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
>> disabled for all. Once set, thi
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
> disabled for all. Once set, this value can not be changed.
What purpose does this securelevel-like property ("O
Hi List,
This is v4 of the automatic module load restriction series.
v1 and v2 implementation were presented as a stackable LSM [1] [2].
v3 was updated to be integrated with the core kernel inside the
capabilities subsystem as suggested by Kees Cook [3].
This v4 is even better, lot of documentat
13 matches
Mail list logo
