On 09/01/2018 06:04 AM, Tetsuo Handa wrote:
> On 2017/10/22 2:17, Casey Schaufler wrote:
>>> As one year elapsed since I proposed CaitSith for upstream, I'd like to
>>> hear the status again. I looked at
>>> http://schd.ws/hosted_files/lss2017/8b/201709-LinuxSecuritySummit-Stacking.pdf
>>> .
>>>
On 09/01/2018 06:04 AM, Tetsuo Handa wrote:
> On 2017/10/22 2:17, Casey Schaufler wrote:
>>> As one year elapsed since I proposed CaitSith for upstream, I'd like to
>>> hear the status again. I looked at
>>> http://schd.ws/hosted_files/lss2017/8b/201709-LinuxSecuritySummit-Stacking.pdf
>>> .
>>>
On 2017/10/22 2:17, Casey Schaufler wrote:
>> As one year elapsed since I proposed CaitSith for upstream, I'd like to
>> hear the status again. I looked at
>> http://schd.ws/hosted_files/lss2017/8b/201709-LinuxSecuritySummit-Stacking.pdf
>> .
>> How is ETA for Security Module Stacking? Is it a
On 2017/10/22 2:17, Casey Schaufler wrote:
>> As one year elapsed since I proposed CaitSith for upstream, I'd like to
>> hear the status again. I looked at
>> http://schd.ws/hosted_files/lss2017/8b/201709-LinuxSecuritySummit-Stacking.pdf
>> .
>> How is ETA for Security Module Stacking? Is it a
On 10/21/2017 3:59 AM, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
>> John Johansen wrote:
>>> On 05/20/2017 09:59 PM, Tetsuo Handa wrote:
John Johansen wrote:
> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
>> Tetsuo Handa wrote:
>>> John Johansen wrote:
> In order to
On 10/21/2017 3:59 AM, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
>> John Johansen wrote:
>>> On 05/20/2017 09:59 PM, Tetsuo Handa wrote:
John Johansen wrote:
> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
>> Tetsuo Handa wrote:
>>> John Johansen wrote:
> In order to
Tetsuo Handa wrote:
> John Johansen wrote:
> > On 05/20/2017 09:59 PM, Tetsuo Handa wrote:
> > > John Johansen wrote:
> > >> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
> > >>> Tetsuo Handa wrote:
> > John Johansen wrote:
> > >> In order to minimize the burden of reviewing, this patchset
Tetsuo Handa wrote:
> John Johansen wrote:
> > On 05/20/2017 09:59 PM, Tetsuo Handa wrote:
> > > John Johansen wrote:
> > >> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
> > >>> Tetsuo Handa wrote:
> > John Johansen wrote:
> > >> In order to minimize the burden of reviewing, this patchset
John Johansen wrote:
> On 05/20/2017 09:59 PM, Tetsuo Handa wrote:
> > John Johansen wrote:
> >> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
> >>> Tetsuo Handa wrote:
> John Johansen wrote:
> >> In order to minimize the burden of reviewing, this patchset implements
> >> only
John Johansen wrote:
> On 05/20/2017 09:59 PM, Tetsuo Handa wrote:
> > John Johansen wrote:
> >> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
> >>> Tetsuo Handa wrote:
> John Johansen wrote:
> >> In order to minimize the burden of reviewing, this patchset implements
> >> only
On 05/20/2017 09:59 PM, Tetsuo Handa wrote:
> John Johansen wrote:
>> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
>>> Tetsuo Handa wrote:
John Johansen wrote:
>> In order to minimize the burden of reviewing, this patchset implements
>> only functionality of checking program execution
On 05/20/2017 09:59 PM, Tetsuo Handa wrote:
> John Johansen wrote:
>> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
>>> Tetsuo Handa wrote:
John Johansen wrote:
>> In order to minimize the burden of reviewing, this patchset implements
>> only functionality of checking program execution
John Johansen wrote:
> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
> > Tetsuo Handa wrote:
> >> John Johansen wrote:
> In order to minimize the burden of reviewing, this patchset implements
> only functionality of checking program execution requests (i.e. execve()
> system call)
John Johansen wrote:
> On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
> > Tetsuo Handa wrote:
> >> John Johansen wrote:
> In order to minimize the burden of reviewing, this patchset implements
> only functionality of checking program execution requests (i.e. execve()
> system call)
On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
>> John Johansen wrote:
In order to minimize the burden of reviewing, this patchset implements
only functionality of checking program execution requests (i.e. execve()
system call) using pathnames. I'm planning to add
On 11/22/2016 10:31 PM, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
>> John Johansen wrote:
In order to minimize the burden of reviewing, this patchset implements
only functionality of checking program execution requests (i.e. execve()
system call) using pathnames. I'm planning to add
Tetsuo Handa wrote:
> John Johansen wrote:
> > > In order to minimize the burden of reviewing, this patchset implements
> > > only functionality of checking program execution requests (i.e. execve()
> > > system call) using pathnames. I'm planning to add other functionalities
> > > after this
Tetsuo Handa wrote:
> John Johansen wrote:
> > > In order to minimize the burden of reviewing, this patchset implements
> > > only functionality of checking program execution requests (i.e. execve()
> > > system call) using pathnames. I'm planning to add other functionalities
> > > after this
John Johansen wrote:
> On 10/21/2016 05:49 AM, Tetsuo Handa wrote:
> > CaitSith (acronym for "Characteristic action inspection tool. See if
> > this helps.") is an LSM based access control implementation which uses
> > action check list (acl) as policy syntax.
> >
>
> << snip >>
>
> > CaitSith
John Johansen wrote:
> On 10/21/2016 05:49 AM, Tetsuo Handa wrote:
> > CaitSith (acronym for "Characteristic action inspection tool. See if
> > this helps.") is an LSM based access control implementation which uses
> > action check list (acl) as policy syntax.
> >
>
> << snip >>
>
> > CaitSith
On 10/21/2016 05:49 AM, Tetsuo Handa wrote:
> CaitSith (acronym for "Characteristic action inspection tool. See if
> this helps.") is an LSM based access control implementation which uses
> action check list (acl) as policy syntax.
>
<< snip >>
> CaitSith tries to remove many limitations which
On 10/21/2016 05:49 AM, Tetsuo Handa wrote:
> CaitSith (acronym for "Characteristic action inspection tool. See if
> this helps.") is an LSM based access control implementation which uses
> action check list (acl) as policy syntax.
>
<< snip >>
> CaitSith tries to remove many limitations which
On 10/23/2016 09:44 PM, James Morris wrote:
> On Fri, 21 Oct 2016, Tetsuo Handa wrote:
>
>> (1) CaitSith can use both string / numeric arguments (like TOMOYO and
>> AppArmor) and security labels (like SELinux and Smack). There is no
>> reason that access control implementation must
On 10/23/2016 09:44 PM, James Morris wrote:
> On Fri, 21 Oct 2016, Tetsuo Handa wrote:
>
>> (1) CaitSith can use both string / numeric arguments (like TOMOYO and
>> AppArmor) and security labels (like SELinux and Smack). There is no
>> reason that access control implementation must
On Fri, 21 Oct 2016, Tetsuo Handa wrote:
> (1) CaitSith can use both string / numeric arguments (like TOMOYO and
> AppArmor) and security labels (like SELinux and Smack). There is no
> reason that access control implementation must not use both.
>
I believe that AppArmor will be
On Fri, 21 Oct 2016, Tetsuo Handa wrote:
> (1) CaitSith can use both string / numeric arguments (like TOMOYO and
> AppArmor) and security labels (like SELinux and Smack). There is no
> reason that access control implementation must not use both.
>
I believe that AppArmor will be
CaitSith (acronym for "Characteristic action inspection tool. See if
this helps.") is an LSM based access control implementation which uses
action check list (acl) as policy syntax.
Syntax of an acl block is shown below.
acl "Action" "Whether to check Action or not"
"Decision1" "Whether to
CaitSith (acronym for "Characteristic action inspection tool. See if
this helps.") is an LSM based access control implementation which uses
action check list (acl) as policy syntax.
Syntax of an acl block is shown below.
acl "Action" "Whether to check Action or not"
"Decision1" "Whether to
28 matches
Mail list logo