On Fri, 31 Aug 2012, Kees Cook wrote:
> Given that several distros use (or want to use) Yama, I think that's
> reason enough for this. I think it's important for us to take a
> practical approach here, and having the big LSMs each hook Yama instead
> of doing this in a single global place will
On Fri, 31 Aug 2012, Kees Cook wrote:
Given that several distros use (or want to use) Yama, I think that's
reason enough for this. I think it's important for us to take a
practical approach here, and having the big LSMs each hook Yama instead
of doing this in a single global place will
Kees Cook writes:
> On Fri, Aug 31, 2012 at 8:31 PM, Eric W. Biederman
> wrote:
>> Eric Paris writes:
>>
>>> On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
>>> wrote:
>>>
>> Having taken the time now to vet Yama ugh. Having Yama enabled if
>> simply compiled in breaks using gdb to attach
On Fri, Aug 31, 2012 at 8:31 PM, Eric W. Biederman
wrote:
> Eric Paris writes:
>
>> On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
>> wrote:
>>
>>> From a overal kernel maintenance and use perspective the unconditional
>>> enablement is a pain.
>>>
>>> We long ago established the principle
Eric Paris writes:
> On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
> wrote:
>
>> From a overal kernel maintenance and use perspective the unconditional
>> enablement is a pain.
>>
>> We long ago established the principle that compiling additional code
>> into the kernel should not change
On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
wrote:
> From a overal kernel maintenance and use perspective the unconditional
> enablement is a pain.
>
> We long ago established the principle that compiling additional code
> into the kernel should not change the semenatics of the kernel.
>
Eric Paris writes:
> On Fri, Aug 31, 2012 at 2:39 PM, Alan Cox wrote:
>> On Fri, 31 Aug 2012 14:31:26 -0700
>> Kees Cook wrote:
>>
>>> Unconditionally call Yama, no matter what LSM module is selected.
>
>> Not a good plan. What happens when everyone decides to stack every module
>> by
On Fri, Aug 31, 2012 at 2:39 PM, Alan Cox wrote:
> On Fri, 31 Aug 2012 14:31:26 -0700
> Kees Cook wrote:
>
>> Unconditionally call Yama, no matter what LSM module is selected.
> Not a good plan. What happens when everyone decides to stack every module
> by ifdeffing in the kernel - mayhem. I'm
On Fri, 31 Aug 2012 14:31:26 -0700
Kees Cook wrote:
> Unconditionally call Yama, no matter what LSM module is selected.
>
> Ubuntu and Chrome OS already carry patches to do this, and Fedora has
> voiced interest in doing this as well. Instead of having everyone carry
> these patches, just
Unconditionally call Yama, no matter what LSM module is selected.
Ubuntu and Chrome OS already carry patches to do this, and Fedora has
voiced interest in doing this as well. Instead of having everyone carry
these patches, just switch Yama to being unconditional when compiled
into the kernel.
Unconditionally call Yama, no matter what LSM module is selected.
Ubuntu and Chrome OS already carry patches to do this, and Fedora has
voiced interest in doing this as well. Instead of having everyone carry
these patches, just switch Yama to being unconditional when compiled
into the kernel.
On Fri, 31 Aug 2012 14:31:26 -0700
Kees Cook keesc...@chromium.org wrote:
Unconditionally call Yama, no matter what LSM module is selected.
Ubuntu and Chrome OS already carry patches to do this, and Fedora has
voiced interest in doing this as well. Instead of having everyone carry
these
On Fri, Aug 31, 2012 at 2:39 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Fri, 31 Aug 2012 14:31:26 -0700
Kees Cook keesc...@chromium.org wrote:
Unconditionally call Yama, no matter what LSM module is selected.
Not a good plan. What happens when everyone decides to stack every module
by
Eric Paris epa...@parisplace.org writes:
On Fri, Aug 31, 2012 at 2:39 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Fri, 31 Aug 2012 14:31:26 -0700
Kees Cook keesc...@chromium.org wrote:
Unconditionally call Yama, no matter what LSM module is selected.
Not a good plan. What happens when
On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
ebied...@xmission.com wrote:
From a overal kernel maintenance and use perspective the unconditional
enablement is a pain.
We long ago established the principle that compiling additional code
into the kernel should not change the semenatics
Eric Paris epa...@parisplace.org writes:
On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
ebied...@xmission.com wrote:
From a overal kernel maintenance and use perspective the unconditional
enablement is a pain.
We long ago established the principle that compiling additional code
into
On Fri, Aug 31, 2012 at 8:31 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Eric Paris epa...@parisplace.org writes:
On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
ebied...@xmission.com wrote:
From a overal kernel maintenance and use perspective the unconditional
enablement is a
Kees Cook keesc...@chromium.org writes:
On Fri, Aug 31, 2012 at 8:31 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Eric Paris epa...@parisplace.org writes:
On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Having taken the time now to vet Yama ugh.
18 matches
Mail list logo
