On 12/12/2017 11:56 AM, Kees Cook wrote:
On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott wrote:
On 12/12/2017 11:23 AM, Kees Cook wrote:
On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote:
Hello,
Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec:
On 12/12/2017 11:56 AM, Kees Cook wrote:
On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott wrote:
On 12/12/2017 11:23 AM, Kees Cook wrote:
On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote:
Hello,
Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
races with
On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott wrote:
> On 12/12/2017 11:23 AM, Kees Cook wrote:
>>
>> On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote:
>>>
>>> Hello,
>>>
>>> Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
>>> races
On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott wrote:
> On 12/12/2017 11:23 AM, Kees Cook wrote:
>>
>> On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote:
>>>
>>> Hello,
>>>
>>> Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
>>> races with prlimit()" that made it into
On 12/12/2017 11:23 AM, Kees Cook wrote:
On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote:
Hello,
Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
races with prlimit()" that made it into 4.14.4 effectively changes the default
hard RLIMIT_STACK on
On 12/12/2017 11:23 AM, Kees Cook wrote:
On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote:
Hello,
Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
races with prlimit()" that made it into 4.14.4 effectively changes the default
hard RLIMIT_STACK on machines with
On Tuesday, 12 December 2017 20:23:47 CET Kees Cook wrote:
> This is an interesting state for the system to be in, though, it means
> AT_SECURE is being set for virtually all processes too? I would expect
> that might break a lot too (but clearly it hasn't).
Not really. AT_SECURE is set only for
On Tuesday, 12 December 2017 20:23:47 CET Kees Cook wrote:
> This is an interesting state for the system to be in, though, it means
> AT_SECURE is being set for virtually all processes too? I would expect
> that might break a lot too (but clearly it hasn't).
Not really. AT_SECURE is set only for
On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote:
> Hello,
>
> Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
> races with prlimit()" that made it into 4.14.4 effectively changes the default
> hard RLIMIT_STACK on machines with SELinux (seen on Fedora
On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote:
> Hello,
>
> Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
> races with prlimit()" that made it into 4.14.4 effectively changes the default
> hard RLIMIT_STACK on machines with SELinux (seen on Fedora 27).
>
>
> Of course this can be somewhat worked around by adjusting the SELinux policy
> (allowing blanket noatsecure permission for init_t and possibly others) or
> by pam_limits (for components using PAM).
Correction: pam_limits also usually doesn't help here, as it's often followed
by another
> Of course this can be somewhat worked around by adjusting the SELinux policy
> (allowing blanket noatsecure permission for init_t and possibly others) or
> by pam_limits (for components using PAM).
Correction: pam_limits also usually doesn't help here, as it's often followed
by another
Hello,
Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
races with prlimit()" that made it into 4.14.4 effectively changes the default
hard RLIMIT_STACK on machines with SELinux (seen on Fedora 27).
selinux_bprm_set_creds() sets bprm->secureexec for any SELinux domain
Hello,
Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
races with prlimit()" that made it into 4.14.4 effectively changes the default
hard RLIMIT_STACK on machines with SELinux (seen on Fedora 27).
selinux_bprm_set_creds() sets bprm->secureexec for any SELinux domain
14 matches
Mail list logo