This fixes the yama bug #1209492 but lets administrators still add extra restrictions if desired. This patch should apply as is against both f22 and master.
--- 10-yama-ptrace.conf | 30 ++++++++++++++++++++++++++++++ kernel.spec | 11 +++++++++++ 2 files changed, 41 insertions(+) create mode 100644 10-yama-ptrace.conf
diff --git a/10-yama-ptrace.conf b/10-yama-ptrace.conf new file mode 100644 index 0000000..bcf0e69 --- /dev/null +++ b/10-yama-ptrace.conf @@ -0,0 +1,30 @@ +# The ptrace system call is used for interprocess services, communication +# and introspection (like synchronisation, signaling, debugging, tracing +# and profiling) of processes. +# +# Usage of ptrace is restricted by normal user permissions. Normal +# unprivileged processes cannot interact through ptrace with processes +# that they cannot send signals to or processes that are running set-uid +# or set-gid. +# +# yama ptrace scope can be used to reduce these permissions even more. +# This should normally not be done because it will break various programs +# relying on the default ptrace security restrictions. But can be used +# if you don't have any other way to separate processes in their own +# domains. A different way to restrict ptrace is to set the selinux +# deny_ptrace boolean. Both mechanisms will break some programs relying +# on the ptrace system call and might force users to elevate their +# priviliges to root to do their work. +# +# For more information see Documentation/security/Yama.txt in the kernel +# sources. +# +# This runtime kernel parameter can be set to the following options: +# (Note that setting this to anything except zero will break programs!) +# +# 0 - Normal ptrace security permissions. +# 1 - Restricted ptrace. Only child processes plus normal permissions. +# 2 - Admin-only attach. Only executables with CAP_SYS_PTRACE. +# 3 - No attach. No process may call ptrace at all. Irrevocable. +# +kernel.yama.ptrace_scope = 0 diff --git a/kernel.spec b/kernel.spec index dfc4500..87efd85 100644 --- a/kernel.spec +++ b/kernel.spec @@ -460,6 +460,9 @@ Source1000: config-local Source2000: cpupower.service Source2001: cpupower.config
+# Default sysctl files +Source3000: 10-yama-ptrace.conf + # Here should be only the patches up to the upstream canonical Linus tree.
# For a stable release kernel @@ -1711,6 +1714,10 @@ BuildKernel() { rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/vdso/.build-id %endif
+ # Install default sysctl settings. + %{__install} -D -m 444 %{SOURCE3000} \ + $RPM_BUILD_ROOT%{_sysctldir}/10-yama-ptrace-$KernelVer.conf + # And save the headers/makefiles etc for building modules against # # This all looks scary, but the end result is supposed to be: @@ -2342,6 +2349,7 @@ fi /lib/modules/%{KVERREL}%{?2:+%{2}}/vdso\ /etc/ld.so.conf.d/kernel-%{KVERREL}%{?2:+%{2}}.conf\ %endif\ +%config(noreplace) %{_sysctldir}/10-yama-ptrace-%{KVERREL}%{?2:+%{2}}.conf\ /lib/modules/%{KVERREL}%{?2:+%{2}}/modules.*\ %{expand:%%files -f kernel-%{?2:%{2}-}modules.list %{?2:%{2}-}modules}\ %defattr(-,root,root)\ @@ -2375,6 +2383,9 @@ fi # # %changelog +* Thu Jun 23 2015 Mark Wielaard mjw@redhat.com +- Add 10-yama-ptrace.conf (rhbz 1209492) + * Thu Jun 18 2015 Josh Boyer jwboyer@fedoraproject.org - Add patch to fix touchpad issues on Razer machines (rhbz 1227891)
On Tue, Jun 23, 2015 at 2:04 AM, Mark Wielaard mjw@redhat.com wrote:
This fixes the yama bug #1209492 but lets administrators still add extra restrictions if desired. This patch should apply as is against both f22 and master.
10-yama-ptrace.conf | 30 ++++++++++++++++++++++++++++++ kernel.spec | 11 +++++++++++ 2 files changed, 41 insertions(+) create mode 100644 10-yama-ptrace.conf
diff --git a/10-yama-ptrace.conf b/10-yama-ptrace.conf new file mode 100644 index 0000000..bcf0e69 --- /dev/null +++ b/10-yama-ptrace.conf @@ -0,0 +1,30 @@ +# The ptrace system call is used for interprocess services, communication +# and introspection (like synchronisation, signaling, debugging, tracing +# and profiling) of processes. +# +# Usage of ptrace is restricted by normal user permissions. Normal +# unprivileged processes cannot interact through ptrace with processes +# that they cannot send signals to or processes that are running set-uid +# or set-gid. +# +# yama ptrace scope can be used to reduce these permissions even more. +# This should normally not be done because it will break various programs +# relying on the default ptrace security restrictions. But can be used +# if you don't have any other way to separate processes in their own +# domains. A different way to restrict ptrace is to set the selinux +# deny_ptrace boolean. Both mechanisms will break some programs relying +# on the ptrace system call and might force users to elevate their +# priviliges to root to do their work. +# +# For more information see Documentation/security/Yama.txt in the kernel +# sources. +# +# This runtime kernel parameter can be set to the following options: +# (Note that setting this to anything except zero will break programs!) +# +# 0 - Normal ptrace security permissions. +# 1 - Restricted ptrace. Only child processes plus normal permissions. +# 2 - Admin-only attach. Only executables with CAP_SYS_PTRACE. +# 3 - No attach. No process may call ptrace at all. Irrevocable. +# +kernel.yama.ptrace_scope = 0
The upstream default is 1 here, correct? It might be worth noting that.
diff --git a/kernel.spec b/kernel.spec index dfc4500..87efd85 100644 --- a/kernel.spec +++ b/kernel.spec @@ -460,6 +460,9 @@ Source1000: config-local Source2000: cpupower.service Source2001: cpupower.config
+# Default sysctl files +Source3000: 10-yama-ptrace.conf
We don't ship any other sysctl files in the kernel package. I'm really hesitant to add this here, as we try and keep the kernel package as close to "kernel-only" as we can. The systemd package current ships the others that I'm aware of.
# Here should be only the patches up to the upstream canonical Linus tree.
# For a stable release kernel @@ -1711,6 +1714,10 @@ BuildKernel() { rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/vdso/.build-id %endif
- # Install default sysctl settings.
- %{__install} -D -m 444 %{SOURCE3000} \
$RPM_BUILD_ROOT%{_sysctldir}/10-yama-ptrace-$KernelVer.conf
Help me out, is _sysctldir defined as /etc/sysctl.d or /usr/lib/sysctl.d/ ? The latter is where this file should go in any case.
josh
On Tue, 2015-06-23 at 07:25 -0400, Josh Boyer wrote:
The upstream default is 1 here, correct? It might be worth noting that.
Right, when CONFIG_SECURITY_YAMA is enabled. Added that to the description. Updated patch attached.
diff --git a/kernel.spec b/kernel.spec index dfc4500..87efd85 100644 --- a/kernel.spec +++ b/kernel.spec @@ -460,6 +460,9 @@ Source1000: config-local Source2000: cpupower.service Source2001: cpupower.config
+# Default sysctl files +Source3000: 10-yama-ptrace.conf
We don't ship any other sysctl files in the kernel package.
But we do ship other service and config files. Which is what this patch modeled after. The alternative fix for the kernel is to just disable yama completely. But then the admin cannot add any more yama based restrictions at all if they wanted.
Help me out, is _sysctldir defined as /etc/sysctl.d or /usr/lib/sysctl.d/ ? The latter is where this file should go in any case.
The latter.
Thanks,
Mark
On Tue, Jun 23, 2015 at 9:09 AM, Mark Wielaard mjw@redhat.com wrote:
On Tue, 2015-06-23 at 07:25 -0400, Josh Boyer wrote:
The upstream default is 1 here, correct? It might be worth noting that.
Right, when CONFIG_SECURITY_YAMA is enabled. Added that to the description. Updated patch attached.
diff --git a/kernel.spec b/kernel.spec index dfc4500..87efd85 100644 --- a/kernel.spec +++ b/kernel.spec @@ -460,6 +460,9 @@ Source1000: config-local Source2000: cpupower.service Source2001: cpupower.config
+# Default sysctl files +Source3000: 10-yama-ptrace.conf
We don't ship any other sysctl files in the kernel package.
But we do ship other service and config files. Which is what this patch modeled after. The alternative fix for the kernel is to just disable yama completely. But then the admin cannot add any more yama based restrictions at all if they wanted.
I suggested submitting this to the systemd package to sit with all the rest of the sysctl options we ship in the distro. I wasn't saying don't ship it. I was saying keep it with everything else.
Help me out, is _sysctldir defined as /etc/sysctl.d or /usr/lib/sysctl.d/ ? The latter is where this file should go in any case.
The latter.
OK, good.
josh
Hi,
Added systemd-maint to the CC.
On Tue, 2015-06-23 at 09:11 -0400, Josh Boyer wrote:
On Tue, Jun 23, 2015 at 9:09 AM, Mark Wielaard mjw@redhat.com wrote:
diff --git a/kernel.spec b/kernel.spec index dfc4500..87efd85 100644 --- a/kernel.spec +++ b/kernel.spec @@ -460,6 +460,9 @@ Source1000: config-local Source2000: cpupower.service Source2001: cpupower.config
+# Default sysctl files +Source3000: 10-yama-ptrace.conf
We don't ship any other sysctl files in the kernel package.
But we do ship other service and config files. Which is what this patch modeled after. The alternative fix for the kernel is to just disable yama completely. But then the admin cannot add any more yama based restrictions at all if they wanted.
I suggested submitting this to the systemd package to sit with all the rest of the sysctl options we ship in the distro. I wasn't saying don't ship it. I was saying keep it with everything else.
OK. I made a patch for the systemd package and attached it to a new bug: https://bugzilla.redhat.com/show_bug.cgi?id=1234951 Once that patch is applied to the f22 systemd package the kernel package should probably depend on the version in which it is fixed.
Thanks,
Mark
On Tue, 2015-06-23 at 16:56 +0200, Mark Wielaard wrote:
On Tue, 2015-06-23 at 09:11 -0400, Josh Boyer wrote:
On Tue, Jun 23, 2015 at 9:09 AM, Mark Wielaard mjw@redhat.com wrote:
We don't ship any other sysctl files in the kernel package.
But we do ship other service and config files. Which is what this patch modeled after. The alternative fix for the kernel is to just disable yama completely. But then the admin cannot add any more yama based restrictions at all if they wanted.
I suggested submitting this to the systemd package to sit with all the rest of the sysctl options we ship in the distro. I wasn't saying don't ship it. I was saying keep it with everything else.
OK. I made a patch for the systemd package and attached it to a new bug: https://bugzilla.redhat.com/show_bug.cgi?id=1234951 Once that patch is applied to the f22 systemd package the kernel package should probably depend on the version in which it is fixed.
The systemd maintainers decided they don't want to carry sysctl files for the kernel. So I have attached an alternative patch to https://bugzilla.redhat.com/show_bug.cgi?id=1209492 (an to this email) to revert the yama config setting to the upstream default. This fixes all packages relying on the default ptrace security settings. The patch is against the f22 kernel git repo (but I saw mention of some alternate git tree, so please let me know if I should regenerate it against something else).
Thanks,
Mark
On Mon, Jul 6, 2015 at 9:10 AM, Mark Wielaard mjw@redhat.com wrote:
On Tue, 2015-06-23 at 16:56 +0200, Mark Wielaard wrote:
On Tue, 2015-06-23 at 09:11 -0400, Josh Boyer wrote:
On Tue, Jun 23, 2015 at 9:09 AM, Mark Wielaard mjw@redhat.com wrote:
We don't ship any other sysctl files in the kernel package.
But we do ship other service and config files. Which is what this patch modeled after. The alternative fix for the kernel is to just disable yama completely. But then the admin cannot add any more yama based restrictions at all if they wanted.
I suggested submitting this to the systemd package to sit with all the rest of the sysctl options we ship in the distro. I wasn't saying don't ship it. I was saying keep it with everything else.
OK. I made a patch for the systemd package and attached it to a new bug: https://bugzilla.redhat.com/show_bug.cgi?id=1234951 Once that patch is applied to the f22 systemd package the kernel package should probably depend on the version in which it is fixed.
The systemd maintainers decided they don't want to carry sysctl files for the kernel. So I have attached an alternative patch to
No, that isn't what they decided. They pushed a change to systemd that contained the sysctl file:
commit 90aeeef683cc21ad43162f1e45a08d335776825e Author: Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl Date: Sat Jun 27 14:00:14 2015 -0400
Add example file with yama config
it simply lacks the value you desire.
https://bugzilla.redhat.com/show_bug.cgi?id=1209492 (an to this email) to revert the yama config setting to the upstream default. This fixes
That would make the sysctl file systemd just added on your request completely pointless and actually incorrect because changing the value wouldn't work at all.
josh
On Mon, 2015-07-06 at 09:39 -0400, Josh Boyer wrote:
On Mon, Jul 6, 2015 at 9:10 AM, Mark Wielaard mjw@redhat.com wrote:
On Tue, 2015-06-23 at 16:56 +0200, Mark Wielaard wrote:
On Tue, 2015-06-23 at 09:11 -0400, Josh Boyer wrote:
On Tue, Jun 23, 2015 at 9:09 AM, Mark Wielaard mjw@redhat.com wrote:
We don't ship any other sysctl files in the kernel package.
But we do ship other service and config files. Which is what this patch modeled after. The alternative fix for the kernel is to just disable yama completely. But then the admin cannot add any more yama based restrictions at all if they wanted.
I suggested submitting this to the systemd package to sit with all the rest of the sysctl options we ship in the distro. I wasn't saying don't ship it. I was saying keep it with everything else.
OK. I made a patch for the systemd package and attached it to a new bug: https://bugzilla.redhat.com/show_bug.cgi?id=1234951 Once that patch is applied to the f22 systemd package the kernel package should probably depend on the version in which it is fixed.
The systemd maintainers decided they don't want to carry sysctl files for the kernel. So I have attached an alternative patch to
No, that isn't what they decided. They pushed a change to systemd that contained the sysctl file:
commit 90aeeef683cc21ad43162f1e45a08d335776825e Author: Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl Date: Sat Jun 27 14:00:14 2015 -0400
Add example file with yama configit simply lacks the value you desire.
It does have the desired value, but it is installed in _pkgdocdir, not in _sysctldir. So it doesn't actuall fix any package that is currently broken.
https://bugzilla.redhat.com/show_bug.cgi?id=1209492 (an to this email) to revert the yama config setting to the upstream default. This fixes
That would make the sysctl file systemd just added on your request completely pointless and actually incorrect because changing the value wouldn't work at all.
Yes, that is a downside of the patch. You won't be able to switch the default value anymore. But if we cannot do that by installing the sysctl file in either the kernel or systemd the alternative would be to hunt down and fix all individually packages that rely on ptrace working normally. Which seems unattractive to me if the fix in the kernel is so simple.
Cheers,
Mark
On Mon, Jul 06, 2015 at 03:49:18PM +0200, Mark Wielaard wrote:
On Mon, 2015-07-06 at 09:39 -0400, Josh Boyer wrote:
On Mon, Jul 6, 2015 at 9:10 AM, Mark Wielaard mjw@redhat.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1209492 (an to this email) to revert the yama config setting to the upstream default. This fixes
That would make the sysctl file systemd just added on your request completely pointless and actually incorrect because changing the value wouldn't work at all.
Yes, that is a downside of the patch. You won't be able to switch the default value anymore. But if we cannot do that by installing the sysctl file in either the kernel or systemd the alternative would be to hunt down and fix all individually packages that rely on ptrace working normally. Which seems unattractive to me if the fix in the kernel is so simple.
It took some time but we eventually came up with a solution. Stephen Smalley who added the support for yama originally to the fedora kernel agrees with the approach. And Paul Moore is making sure this gets merged upstream. Attached are commits for f22, f23 and master. Please let me know if you need anything else to get these applied.
Thanks,
Mark
On Sat, Aug 01, 2015 at 10:08:14PM +0200, Mark Wielaard wrote:
On Mon, Jul 06, 2015 at 03:49:18PM +0200, Mark Wielaard wrote:
On Mon, 2015-07-06 at 09:39 -0400, Josh Boyer wrote:
On Mon, Jul 6, 2015 at 9:10 AM, Mark Wielaard mjw@redhat.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1209492 (an to this email) to revert the yama config setting to the upstream default. This fixes
That would make the sysctl file systemd just added on your request completely pointless and actually incorrect because changing the value wouldn't work at all.
Yes, that is a downside of the patch. You won't be able to switch the default value anymore. But if we cannot do that by installing the sysctl file in either the kernel or systemd the alternative would be to hunt down and fix all individually packages that rely on ptrace working normally. Which seems unattractive to me if the fix in the kernel is so simple.
It took some time but we eventually came up with a solution. Stephen Smalley who added the support for yama originally to the fedora kernel agrees with the approach. And Paul Moore is making sure this gets merged upstream. Attached are commits for f22, f23 and master. Please let me know if you need anything else to get these applied.
So... yama consists of one thing, the ptrace scope setting. Your patch sets the ptrace scope setting back to 0. So yama would be compiled in, but disabled.
Yama was added for a reason. So far this reason has not gone away. Your patch would make users susceptible to the vulnerability, by default, again.
Zbyszek
Thanks,
Mark
From cbe1bca54f09d878c5551ca53a923b879e7230f9 Mon Sep 17 00:00:00 2001 From: Mark Wielaard mjw@redhat.com Date: Sat, 1 Aug 2015 19:18:10 +0200 Subject: [PATCH] Set yama ptrace_scope default (rhbz 1209492)
config-generic | 2 ++ kernel.spec | 9 ++++++ yama-set-ptrace_scope-default.patch | 61 +++++++++++++++++++++++++++++++++++++ 3 files changed, 72 insertions(+) create mode 100644 yama-set-ptrace_scope-default.patch
diff --git a/config-generic b/config-generic index 24a3387..3d84ed0 100644 --- a/config-generic +++ b/config-generic @@ -4585,7 +4585,9 @@ CONFIG_SECURITY_SELINUX_AVC_STATS=y # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set +# (rhbz 1209492) we only want yama enabled with ptrace_scope set to zero. CONFIG_SECURITY_YAMA=y +CONFIG_SECURITY_YAMA_PTRACE_DEFAULT=0 CONFIG_SECURITY_YAMA_STACKED=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y diff --git a/kernel.spec b/kernel.spec index 792f833..51df973 100644 --- a/kernel.spec +++ b/kernel.spec @@ -645,6 +645,9 @@ Patch26260: x86-nmi-64-Improve-nested-NMI-comments.patch Patch26261: x86-nmi-64-Reorder-nested-NMI-checks.patch Patch26262: x86-nmi-64-Use-DF-to-avoid-userspace-RSP-confusing-n.patch
+# rhbz 1209492 +Patch26263: yama-set-ptrace_scope-default.patch
# END OF PATCH DEFINITIONS
%endif @@ -1408,6 +1411,9 @@ ApplyPatch x86-nmi-64-Improve-nested-NMI-comments.patch ApplyPatch x86-nmi-64-Reorder-nested-NMI-checks.patch ApplyPatch x86-nmi-64-Use-DF-to-avoid-userspace-RSP-confusing-n.patch
+# rhbz 1209492 +ApplyPatch yama-set-ptrace_scope-default.patch
# END OF PATCH APPLICATIONS
%endif @@ -2258,6 +2264,9 @@ fi # # %changelog +* Sat Aug 01 2015 Mark Wielaard mjw@redhat.com +- Set yama ptrace_scope default (rhbz 1209492)
- Wed Jul 29 2015 Laura Abbott labbott@redhat.com - 4.1.3-201
- tag and build for CVE fixes
diff --git a/yama-set-ptrace_scope-default.patch b/yama-set-ptrace_scope-default.patch new file mode 100644 index 0000000..5e36e56 --- /dev/null +++ b/yama-set-ptrace_scope-default.patch @@ -0,0 +1,61 @@ +yama: make the default ptrace_scope value a Kconfig option
+From: Paul Moore pmoore@redhat.com
+By default a Yama enabled system boots into a "restricted ptrace" +mode, while desirable from a security point of view, it does alter +the classic Linux ptrace() permissions and is seen by some as a +serious API breakage. It is possible to alter the ptrace_scope at +runtime through the normal sysctl methods, but there are some +distributions which insist on using the kernel compile time defaults +for Yama while at the same time complaining about the API break. +Needless to say, this makes it very difficult to enable Yama in these +distribution kernels.
+This patch creates CONFIG_SECURITY_YAMA_PTRACE_DEFAULT, a new Kconfig +option, which allows a user to set the compile time default for Yama's +ptrace_scope setting. The default value is set to "1" to preserve +Yama's defaults.
+Signed-off-by: Paul Moore pmoore@redhat.com +---
- security/yama/Kconfig | 12 ++++++++++++
- security/yama/yama_lsm.c | 2 +-
- 2 files changed, 13 insertions(+), 1 deletion(-)
+diff --git a/security/yama/Kconfig b/security/yama/Kconfig +index 90c605e..2cf9bad 100644 +--- a/security/yama/Kconfig ++++ b/security/yama/Kconfig +@@ -10,6 +10,18 @@
If you are unsure how to answer this question, answer N.++config SECURITY_YAMA_PTRACE_DEFAULT ++ int "Yama default ptrace_scope value" ++ depends on SECURITY_YAMA ++ range 0 3 ++ default 1 ++ help ++ This sets the default ptrace_scope value as described in ++ Documentation/security/Yama.txt. Historically Yama has always had ++ a default value of 1, enabling some ptrace restrictions, but the ++ classic, unrestricted Linux ptrace behavior is possible with a value ++ of 0. ++
- config SECURITY_YAMA_STACKED
- bool "Yama stacked with other LSMs"
- depends on SECURITY_YAMA
+diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c +index d3c19c9..16a35ec 100644 +--- a/security/yama/yama_lsm.c ++++ b/security/yama/yama_lsm.c +@@ -24,7 +24,7 @@
- #define YAMA_SCOPE_CAPABILITY 2
- #define YAMA_SCOPE_NO_ATTACH 3
+-static int ptrace_scope = YAMA_SCOPE_RELATIONAL; ++static int ptrace_scope = CONFIG_SECURITY_YAMA_PTRACE_DEFAULT;
- /* describe a ptrace relationship for potential exception */
- struct ptrace_relation {
-- 2.4.3
From 1070920f261ff717acfd4b050d2fd1254d86021c Mon Sep 17 00:00:00 2001 From: Mark Wielaard mjw@redhat.com Date: Sat, 1 Aug 2015 19:18:10 +0200 Subject: [PATCH] Set yama ptrace_scope default (rhbz 1209492)
config-generic | 2 ++ kernel.spec | 6 ++++ yama-set-ptrace_scope-default.patch | 61 +++++++++++++++++++++++++++++++++++++ 3 files changed, 69 insertions(+) create mode 100644 yama-set-ptrace_scope-default.patch
diff --git a/config-generic b/config-generic index 8553fc9..9d43fa7 100644 --- a/config-generic +++ b/config-generic @@ -4685,7 +4685,9 @@ CONFIG_SECURITY_SELINUX_AVC_STATS=y # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set +# (rhbz 1209492) we only want yama enabled with ptrace_scope set to zero. CONFIG_SECURITY_YAMA=y +CONFIG_SECURITY_YAMA_PTRACE_DEFAULT=0 CONFIG_SECURITY_YAMA_STACKED=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y diff --git a/kernel.spec b/kernel.spec index 0c0c9ae..3bbe67a 100644 --- a/kernel.spec +++ b/kernel.spec @@ -582,6 +582,9 @@ Patch502: firmware-Drop-WARN-from-usermodehelper_read_trylock-.patch
Patch503: drm-i915-turn-off-wc-mmaps.patch
+# rhbz 1209492 +Patch504: yama-set-ptrace_scope-default.patch
# END OF PATCH DEFINITIONS
%endif @@ -2017,6 +2020,9 @@ fi # # %changelog +* Sat Aug 01 2015 Mark Wielaard mjw@redhat.com +- Set yama ptrace_scope default (rhbz 1209492)
- Fri Jul 31 2015 Josh Boyer jwboyer@fedoraproject.org - 4.2.0-0.rc4.git4.1
- Linux v4.2-rc4-111-g8400935737bf
diff --git a/yama-set-ptrace_scope-default.patch b/yama-set-ptrace_scope-default.patch new file mode 100644 index 0000000..5e36e56 --- /dev/null +++ b/yama-set-ptrace_scope-default.patch @@ -0,0 +1,61 @@ +yama: make the default ptrace_scope value a Kconfig option
+From: Paul Moore pmoore@redhat.com
+By default a Yama enabled system boots into a "restricted ptrace" +mode, while desirable from a security point of view, it does alter +the classic Linux ptrace() permissions and is seen by some as a +serious API breakage. It is possible to alter the ptrace_scope at +runtime through the normal sysctl methods, but there are some +distributions which insist on using the kernel compile time defaults +for Yama while at the same time complaining about the API break. +Needless to say, this makes it very difficult to enable Yama in these +distribution kernels.
+This patch creates CONFIG_SECURITY_YAMA_PTRACE_DEFAULT, a new Kconfig +option, which allows a user to set the compile time default for Yama's +ptrace_scope setting. The default value is set to "1" to preserve +Yama's defaults.
+Signed-off-by: Paul Moore pmoore@redhat.com +---
- security/yama/Kconfig | 12 ++++++++++++
- security/yama/yama_lsm.c | 2 +-
- 2 files changed, 13 insertions(+), 1 deletion(-)
+diff --git a/security/yama/Kconfig b/security/yama/Kconfig +index 90c605e..2cf9bad 100644 +--- a/security/yama/Kconfig ++++ b/security/yama/Kconfig +@@ -10,6 +10,18 @@
If you are unsure how to answer this question, answer N.++config SECURITY_YAMA_PTRACE_DEFAULT ++ int "Yama default ptrace_scope value" ++ depends on SECURITY_YAMA ++ range 0 3 ++ default 1 ++ help ++ This sets the default ptrace_scope value as described in ++ Documentation/security/Yama.txt. Historically Yama has always had ++ a default value of 1, enabling some ptrace restrictions, but the ++ classic, unrestricted Linux ptrace behavior is possible with a value ++ of 0. ++
- config SECURITY_YAMA_STACKED
- bool "Yama stacked with other LSMs"
- depends on SECURITY_YAMA
+diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c +index d3c19c9..16a35ec 100644 +--- a/security/yama/yama_lsm.c ++++ b/security/yama/yama_lsm.c +@@ -24,7 +24,7 @@
- #define YAMA_SCOPE_CAPABILITY 2
- #define YAMA_SCOPE_NO_ATTACH 3
+-static int ptrace_scope = YAMA_SCOPE_RELATIONAL; ++static int ptrace_scope = CONFIG_SECURITY_YAMA_PTRACE_DEFAULT;
- /* describe a ptrace relationship for potential exception */
- struct ptrace_relation {
-- 2.4.3
From 2ce2ef114cff1979c29dd723e954c14749e16f40 Mon Sep 17 00:00:00 2001 From: Mark Wielaard mjw@redhat.com Date: Sat, 1 Aug 2015 19:18:10 +0200 Subject: [PATCH] Set yama ptrace_scope default (rhbz 1209492)
config-generic | 2 ++ kernel.spec | 6 ++++ yama-set-ptrace_scope-default.patch | 61 +++++++++++++++++++++++++++++++++++++ 3 files changed, 69 insertions(+) create mode 100644 yama-set-ptrace_scope-default.patch
diff --git a/config-generic b/config-generic index b7e23de..a607e5b 100644 --- a/config-generic +++ b/config-generic @@ -4686,7 +4686,9 @@ CONFIG_SECURITY_SELINUX_AVC_STATS=y # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set +# (rhbz 1209492) we only want yama enabled with ptrace_scope set to zero. CONFIG_SECURITY_YAMA=y +CONFIG_SECURITY_YAMA_PTRACE_DEFAULT=0 CONFIG_SECURITY_YAMA_STACKED=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y diff --git a/kernel.spec b/kernel.spec index 09bf955..b01e55c 100644 --- a/kernel.spec +++ b/kernel.spec @@ -582,6 +582,9 @@ Patch502: firmware-Drop-WARN-from-usermodehelper_read_trylock-.patch
Patch503: drm-i915-turn-off-wc-mmaps.patch
+# rhbz 1209492 +Patch504: yama-set-ptrace_scope-default.patch
Patch904: kdbus.patch
# END OF PATCH DEFINITIONS @@ -2019,6 +2022,9 @@ fi # # %changelog +* Sat Aug 01 2015 Mark Wielaard mjw@redhat.com +- Set yama ptrace_scope default (rhbz 1209492)
- Fri Jul 31 2015 Josh Boyer jwboyer@fedoraproject.org - 4.2.0-0.rc4.git4.1
- Linux v4.2-rc4-111-g8400935737bf
diff --git a/yama-set-ptrace_scope-default.patch b/yama-set-ptrace_scope-default.patch new file mode 100644 index 0000000..5e36e56 --- /dev/null +++ b/yama-set-ptrace_scope-default.patch @@ -0,0 +1,61 @@ +yama: make the default ptrace_scope value a Kconfig option
+From: Paul Moore pmoore@redhat.com
+By default a Yama enabled system boots into a "restricted ptrace" +mode, while desirable from a security point of view, it does alter +the classic Linux ptrace() permissions and is seen by some as a +serious API breakage. It is possible to alter the ptrace_scope at +runtime through the normal sysctl methods, but there are some +distributions which insist on using the kernel compile time defaults +for Yama while at the same time complaining about the API break. +Needless to say, this makes it very difficult to enable Yama in these +distribution kernels.
+This patch creates CONFIG_SECURITY_YAMA_PTRACE_DEFAULT, a new Kconfig +option, which allows a user to set the compile time default for Yama's +ptrace_scope setting. The default value is set to "1" to preserve +Yama's defaults.
+Signed-off-by: Paul Moore pmoore@redhat.com +---
- security/yama/Kconfig | 12 ++++++++++++
- security/yama/yama_lsm.c | 2 +-
- 2 files changed, 13 insertions(+), 1 deletion(-)
+diff --git a/security/yama/Kconfig b/security/yama/Kconfig +index 90c605e..2cf9bad 100644 +--- a/security/yama/Kconfig ++++ b/security/yama/Kconfig +@@ -10,6 +10,18 @@
If you are unsure how to answer this question, answer N.++config SECURITY_YAMA_PTRACE_DEFAULT ++ int "Yama default ptrace_scope value" ++ depends on SECURITY_YAMA ++ range 0 3 ++ default 1 ++ help ++ This sets the default ptrace_scope value as described in ++ Documentation/security/Yama.txt. Historically Yama has always had ++ a default value of 1, enabling some ptrace restrictions, but the ++ classic, unrestricted Linux ptrace behavior is possible with a value ++ of 0. ++
- config SECURITY_YAMA_STACKED
- bool "Yama stacked with other LSMs"
- depends on SECURITY_YAMA
+diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c +index d3c19c9..16a35ec 100644 +--- a/security/yama/yama_lsm.c ++++ b/security/yama/yama_lsm.c +@@ -24,7 +24,7 @@
- #define YAMA_SCOPE_CAPABILITY 2
- #define YAMA_SCOPE_NO_ATTACH 3
+-static int ptrace_scope = YAMA_SCOPE_RELATIONAL; ++static int ptrace_scope = CONFIG_SECURITY_YAMA_PTRACE_DEFAULT;
- /* describe a ptrace relationship for potential exception */
- struct ptrace_relation {
-- 2.4.3
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Sun, Aug 02, 2015 at 12:57:53AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Sat, Aug 01, 2015 at 10:08:14PM +0200, Mark Wielaard wrote:
On Mon, Jul 06, 2015 at 03:49:18PM +0200, Mark Wielaard wrote:
On Mon, 2015-07-06 at 09:39 -0400, Josh Boyer wrote:
On Mon, Jul 6, 2015 at 9:10 AM, Mark Wielaard mjw@redhat.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1209492 (an to this email) to revert the yama config setting to the upstream default. This fixes
That would make the sysctl file systemd just added on your request completely pointless and actually incorrect because changing the value wouldn't work at all.
Yes, that is a downside of the patch. You won't be able to switch the default value anymore. But if we cannot do that by installing the sysctl file in either the kernel or systemd the alternative would be to hunt down and fix all individually packages that rely on ptrace working normally. Which seems unattractive to me if the fix in the kernel is so simple.
It took some time but we eventually came up with a solution. Stephen Smalley who added the support for yama originally to the fedora kernel agrees with the approach. And Paul Moore is making sure this gets merged upstream. Attached are commits for f22, f23 and master. Please let me know if you need anything else to get these applied.
So... yama consists of one thing, the ptrace scope setting. Your patch sets the ptrace scope setting back to 0. So yama would be compiled in, but disabled.
Yes, see the bug report for the (very long) discussion of why.
Cheers,
Mark
On Saturday, August 01, 2015 10:08:14 PM Mark Wielaard wrote:
On Mon, Jul 06, 2015 at 03:49:18PM +0200, Mark Wielaard wrote:
On Mon, 2015-07-06 at 09:39 -0400, Josh Boyer wrote:
On Mon, Jul 6, 2015 at 9:10 AM, Mark Wielaard mjw@redhat.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1209492 (an to this email) to revert the yama config setting to the upstream default. This fixes
That would make the sysctl file systemd just added on your request completely pointless and actually incorrect because changing the value wouldn't work at all.
Yes, that is a downside of the patch. You won't be able to switch the default value anymore. But if we cannot do that by installing the sysctl file in either the kernel or systemd the alternative would be to hunt down and fix all individually packages that rely on ptrace working normally. Which seems unattractive to me if the fix in the kernel is so simple.
It took some time but we eventually came up with a solution. Stephen Smalley who added the support for yama originally to the fedora kernel agrees with the approach. And Paul Moore is making sure this gets merged upstream. Attached are commits for f22, f23 and master. Please let me know if you need anything else to get these applied.
For the record, I don't really consider this a long term solution as the risks associated with ptrace() still exist. While Mark and a few others on the BZ are happy to discount the risk, I am not. However, my current workload doesn't allow me to keep arguing with Mark so I'm looking into ways to leave Yama in the kernel, but disabled by default. If someone else is able to continue fighting for ptrace restrictions at this point in time, I would suggest adding yourself to the BZ.
Also, it appears that the patch I posted last week isn't really viable upstream due to a general distaste of setting sysctl defaults with CONFIG settings. I have another thought, but I think that discussion is better had on the BZ than on this list.
On Mon, Aug 3, 2015 at 5:49 PM, Paul Moore pmoore@redhat.com wrote:
On Saturday, August 01, 2015 10:08:14 PM Mark Wielaard wrote:
On Mon, Jul 06, 2015 at 03:49:18PM +0200, Mark Wielaard wrote:
On Mon, 2015-07-06 at 09:39 -0400, Josh Boyer wrote:
On Mon, Jul 6, 2015 at 9:10 AM, Mark Wielaard mjw@redhat.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1209492 (an to this email) to revert the yama config setting to the upstream default. This fixes
That would make the sysctl file systemd just added on your request completely pointless and actually incorrect because changing the value wouldn't work at all.
Yes, that is a downside of the patch. You won't be able to switch the default value anymore. But if we cannot do that by installing the sysctl file in either the kernel or systemd the alternative would be to hunt down and fix all individually packages that rely on ptrace working normally. Which seems unattractive to me if the fix in the kernel is so simple.
It took some time but we eventually came up with a solution. Stephen Smalley who added the support for yama originally to the fedora kernel agrees with the approach. And Paul Moore is making sure this gets merged upstream. Attached are commits for f22, f23 and master. Please let me know if you need anything else to get these applied.
For the record, I don't really consider this a long term solution as the risks associated with ptrace() still exist. While Mark and a few others on the BZ are happy to discount the risk, I am not. However, my current workload doesn't allow me to keep arguing with Mark so I'm looking into ways to leave Yama in the kernel, but disabled by default. If someone else is able to continue fighting for ptrace restrictions at this point in time, I would suggest adding yourself to the BZ.
Also, it appears that the patch I posted last week isn't really viable upstream due to a general distaste of setting sysctl defaults with CONFIG settings. I have another thought, but I think that discussion is better had on the BZ than on this list.
Right. This is what I meant by "carrying a patch forever" in the bug. And because of that, I'm probably not going to apply this to Fedora.
If you have a link to the upstream conversation I would appreciate it.
josh
On Monday, August 03, 2015 06:30:13 PM Josh Boyer wrote:
On Mon, Aug 3, 2015 at 5:49 PM, Paul Moore pmoore@redhat.com wrote:
On Saturday, August 01, 2015 10:08:14 PM Mark Wielaard wrote:
On Mon, Jul 06, 2015 at 03:49:18PM +0200, Mark Wielaard wrote:
On Mon, 2015-07-06 at 09:39 -0400, Josh Boyer wrote:
On Mon, Jul 6, 2015 at 9:10 AM, Mark Wielaard mjw@redhat.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1209492 (an to this email) to revert the yama config setting to the upstream default. This fixes
That would make the sysctl file systemd just added on your request completely pointless and actually incorrect because changing the value wouldn't work at all.
Yes, that is a downside of the patch. You won't be able to switch the default value anymore. But if we cannot do that by installing the sysctl file in either the kernel or systemd the alternative would be to hunt down and fix all individually packages that rely on ptrace working normally. Which seems unattractive to me if the fix in the kernel is so simple.
It took some time but we eventually came up with a solution. Stephen Smalley who added the support for yama originally to the fedora kernel agrees with the approach. And Paul Moore is making sure this gets merged upstream. Attached are commits for f22, f23 and master. Please let me know if you need anything else to get these applied.
For the record, I don't really consider this a long term solution as the risks associated with ptrace() still exist. While Mark and a few others on the BZ are happy to discount the risk, I am not. However, my current workload doesn't allow me to keep arguing with Mark so I'm looking into ways to leave Yama in the kernel, but disabled by default. If someone else is able to continue fighting for ptrace restrictions at this point in time, I would suggest adding yourself to the BZ.
Also, it appears that the patch I posted last week isn't really viable upstream due to a general distaste of setting sysctl defaults with CONFIG settings. I have another thought, but I think that discussion is better had on the BZ than on this list.
Right. This is what I meant by "carrying a patch forever" in the bug. And because of that, I'm probably not going to apply this to Fedora.
I was only proposing the patch upstream; if it isn't upstream I don't want us to carry it either.
If you have a link to the upstream conversation I would appreciate it.
Unfortunately, the LSM lists appears to be having some issues at the moment, one of which is that the MARC archives do not appear current.
kernel@lists.fedoraproject.org
-
Josh Boyer -
Mark Wielaard -
Paul Moore -
Zbigniew Jędrzejewski-Szmek