On Thu, 1 Jun 2017 00:10:07 +0900
Tetsuo Handa wrote:
> Alan Cox wrote:
> > > I saw several companies who ship their embedded devices with
> > > single-function LSM modules (e.g. restrict only mount operation and
> > > ptrace operation). What is unfortunate is that their LSM modules had
> > > nev
Alan Cox wrote:
> > I saw several companies who ship their embedded devices with
> > single-function LSM modules (e.g. restrict only mount operation and
> > ptrace operation). What is unfortunate is that their LSM modules had
> > never been proposed for upstream, and thus bugs remained unnoticed.
>
> I saw several companies who ship their embedded devices with
> single-function LSM modules (e.g. restrict only mount operation and
> ptrace operation). What is unfortunate is that their LSM modules had
> never been proposed for upstream, and thus bugs remained unnoticed.
So which of them cannot
James Morris wrote:
> On Wed, 31 May 2017, Tetsuo Handa wrote:
>
> > via lack of ability to use LKM-based LSM modules). My customers cannot
> > afford
> > enabling SELinux, but my customers cannot rebuild their kernels because
> > rebuilding makes it even more difficult to get help from support c
On Wed, 31 May 2017, Tetsuo Handa wrote:
> via lack of ability to use LKM-based LSM modules). My customers cannot afford
> enabling SELinux, but my customers cannot rebuild their kernels because
> rebuilding makes it even more difficult to get help from support centers.
> Therefore, my customers r
James Morris wrote:
> On Tue, 30 May 2017, Alan Cox wrote:
>
> > On Tue, 30 May 2017 23:29:10 +0900
> > Tetsuo Handa wrote:
> >
> > > James Morris wrote:
> > > > On Sun, 28 May 2017, Tetsuo Handa wrote:
> > > >
> > > > > can afford enabling". And we know that we cannot merge all security
> >
On Tue, 30 May 2017 23:29:10 +0900
Tetsuo Handa wrote:
> James Morris wrote:
> > On Sun, 28 May 2017, Tetsuo Handa wrote:
> >
> > > can afford enabling". And we know that we cannot merge all
> > > security modules into mainline. Thus, allowing LKM-based LSM
> > > modules is inevitable.
> >
On Tue, 30 May 2017, Alan Cox wrote:
> On Tue, 30 May 2017 23:29:10 +0900
> Tetsuo Handa wrote:
>
> > James Morris wrote:
> > > On Sun, 28 May 2017, Tetsuo Handa wrote:
> > >
> > > > can afford enabling". And we know that we cannot merge all security
> > > > modules
> > > > into mainline. Th
On Tue, 30 May 2017 23:29:10 +0900
Tetsuo Handa wrote:
> James Morris wrote:
> > On Sun, 28 May 2017, Tetsuo Handa wrote:
> >
> > > can afford enabling". And we know that we cannot merge all security
> > > modules
> > > into mainline. Thus, allowing LKM-based LSM modules is inevitable.
> >
James Morris wrote:
> On Sun, 28 May 2017, Tetsuo Handa wrote:
>
> > can afford enabling". And we know that we cannot merge all security modules
> > into mainline. Thus, allowing LKM-based LSM modules is inevitable.
>
> Nope, it's not inevitable. The LSM API only caters to in-tree users.
>
> I'
On Sun, 28 May 2017, Tetsuo Handa wrote:
> can afford enabling". And we know that we cannot merge all security modules
> into mainline. Thus, allowing LKM-based LSM modules is inevitable.
Nope, it's not inevitable. The LSM API only caters to in-tree users.
I'm not sure why you persist against t
On 5/27/2017 6:26 PM, Tetsuo Handa wrote:
> Kees Cook wrote:
>> On Sat, May 27, 2017 at 4:17 AM, Tetsuo Handa
>> wrote:
>>> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
>>> registration.") treats "struct security_hook_heads" as an implicit array
>>> of "struct list_head" so t
Kees Cook wrote:
> On Sat, May 27, 2017 at 4:17 AM, Tetsuo Handa
> wrote:
> > Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> > registration.") treats "struct security_hook_heads" as an implicit array
> > of "struct list_head" so that we can eliminate code for static
> > initi
On Sat, May 27, 2017 at 4:17 AM, Tetsuo Handa
wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven'
Casey Schaufler wrote:
> > But currently, LSM_HOOK_INIT() macro depends on the address of
> > security_hook_heads being known at compile time. If we use an enum
> > so that LSM_HOOK_INIT() macro does not need to know absolute address of
> > security_hook_heads, it will help us to use that allocator
On 5/27/2017 4:17 AM, Tetsuo Handa wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven't encountere
Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
registration.") treats "struct security_hook_heads" as an implicit array
of "struct list_head" so that we can eliminate code for static
initialization. Although we haven't encountered compilers which do not
treat sizeof(security_hoo
17 matches
Mail list logo