[PATCH] Add 10-yama-ptrace.conf (rhbz 1209492)
by Mark Wielaard
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(a)redhat.com>
+- Add 10-yama-ptrace.conf (rhbz 1209492)
+
* Thu Jun 18 2015 Josh Boyer <jwboyer(a)fedoraproject.org>
- Add patch to fix touchpad issues on Razer machines (rhbz 1227891)
--
2.4.3
8 years, 4 months
Re: [kernel/f21] Make sure acpi brightness_switch is disabled (like forever in Fedora)
by Hans de Goede
Hi Josh,
On 07/28/2014 07:04 PM, Josh Boyer wrote:
> commit e6fe382d1d53d4cdf9b544729dc823d4eab0217c
> Author: Josh Boyer <jwboyer(a)fedoraproject.org>
> Date: Mon Jul 28 13:03:01 2014 -0400
>
> Make sure acpi brightness_switch is disabled (like forever in Fedora)
>
> Upstream reverted the change to turn the ACPI brightness_switch_enabled
> parameter off by default. Revert the revert so we go back to the state
> Fedora has traditionally been in.
Ack, I was planning on doing this myself but you beat me to it, thanks for
taking care of this.
Note that 3.17 will have this patch:
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?...
Which fixes the 2 steps being taken for one keypress problem while
keeping the acpi brightness_switch behavior enabled, so that people who
have an acpi-video controlled backlight and a userspace which does not
do backlight control (e.g. windowmaker).
So for 3.17 we should IMHO drop the revert-revert and stick with
upstream behavior.
Alternatively we could apply that patch now instead of the revert-revert.
Regards,
Hans
8 years, 4 months
failed to build kernel from kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm
by Masami Ichikawa
Hi,
I tried to rebuild kernel from kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm
but I got following error.
Applying: lib/cpumask: Make CPUMASK_OFFSTACK usable without debug dependency
Applying: amd-xgbe-a0: Add support for XGBE on A0
Applying: amd-xgbe-phy-a0: Add support for XGBE PHY on A0
Applying: arm64: avoid needing console= to enable serial console
Applying: usb: make xhci platform driver use 64 bit or 32 bit DMA
Applying: arm64: acpi drop expert patch
Applying: ARM: tegra: usb no reset
error: drivers/usb/core/hub.c: does not exist in index
Patch failed at 0007 ARM: tegra: usb no reset
The copy of the patch that failed is found in:
/home/masami/rpmbuild/BUILD/kernel-4.1.fc23/linux-4.2.0-0.rc3.git3.1.fc23.x86_64/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
error: Bad exit status from /var/tmp/rpm-tmp.yWoA78 (%prep)
Failed patch is this.
masami@f23-test:~$ cat
rpmbuild/BUILD/kernel-4.1.fc23/linux-4.2.0-0.rc3.git3.1.fc23.x86_64/.git/rebase-apply/patch
---
drivers/usb/core/hub.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 43cb2f2e3b43..7f838ec11c81 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4996,6 +4996,13 @@ static void hub_event(struct work_struct *work)
(u16) hub->change_bits[0],
(u16) hub->event_bits[0]);
+ /* Don't disconnect USB-SATA on TrimSlice */
+ if (strcmp(dev_name(hdev->bus->controller), "tegra-ehci.0") == 0) {
+ if ((hdev->state == 7) && (hub->change_bits[0] == 0) &&
+ (hub->event_bits[0] == 0x2))
+ hub->event_bits[0] = 0;
+ }
+
/* Lock the device, then check to see if we were
* disconnected while waiting for the lock to succeed. */
usb_lock_device(hdev);
any idea?
I did following command to rebuild on fedora 23(x86_64) environment.
rpmbuild -bp --target=$(uname -m) kernel.spec
Cheers,
--
Masami Ichikawa
- masami256(a)gmail.com
- masami(a)fedoraproject.org
8 years, 4 months
Fwd: Re: failed to build kernel from kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm
by Lance Lassetter
-------- Original Message --------
From: Lance Lassetter <lancelassetter(a)gmail.com>
Sent: July 26, 2015 9:46:22 AM CDT
To: Josh Boyer <jwboyer(a)fedoraproject.org>
Subject: Re: failed to build kernel from kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm
On July 26, 2015 9:06:35 AM CDT, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>On Sun, Jul 26, 2015 at 9:39 AM, Masami Ichikawa <masami256(a)gmail.com>
>wrote:
>> Hi,
>>
>> I tried to rebuild kernel from
>kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm
>> but I got following error.
>>
>> Applying: lib/cpumask: Make CPUMASK_OFFSTACK usable without debug
>dependency
>> Applying: amd-xgbe-a0: Add support for XGBE on A0
>> Applying: amd-xgbe-phy-a0: Add support for XGBE PHY on A0
>> Applying: arm64: avoid needing console= to enable serial console
>> Applying: usb: make xhci platform driver use 64 bit or 32 bit DMA
>> Applying: arm64: acpi drop expert patch
>> Applying: ARM: tegra: usb no reset
>> error: drivers/usb/core/hub.c: does not exist in index
>> Patch failed at 0007 ARM: tegra: usb no reset
>> The copy of the patch that failed is found in:
>>
>/home/masami/rpmbuild/BUILD/kernel-4.1.fc23/linux-4.2.0-0.rc3.git3.1.fc23.x86_64/.git/rebase-apply/patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am
>--abort".
>> error: Bad exit status from /var/tmp/rpm-tmp.yWoA78 (%prep)
>>
>> Failed patch is this.
>>
>> masami@f23-test:~$ cat
>>
>rpmbuild/BUILD/kernel-4.1.fc23/linux-4.2.0-0.rc3.git3.1.fc23.x86_64/.git/rebase-apply/patch
>> ---
>> drivers/usb/core/hub.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
>> index 43cb2f2e3b43..7f838ec11c81 100644
>> --- a/drivers/usb/core/hub.c
>> +++ b/drivers/usb/core/hub.c
>> @@ -4996,6 +4996,13 @@ static void hub_event(struct work_struct
>*work)
>> (u16) hub->change_bits[0],
>> (u16) hub->event_bits[0]);
>>
>> + /* Don't disconnect USB-SATA on TrimSlice */
>> + if (strcmp(dev_name(hdev->bus->controller), "tegra-ehci.0")
>== 0) {
>> + if ((hdev->state == 7) && (hub->change_bits[0] == 0)
>&&
>> + (hub->event_bits[0] == 0x2))
>> + hub->event_bits[0] = 0;
>> + }
>> +
>> /* Lock the device, then check to see if we were
>> * disconnected while waiting for the lock to succeed. */
>> usb_lock_device(hdev);
>>
>> any idea?
>>
>> I did following command to rebuild on fedora 23(x86_64) environment.
>> rpmbuild -bp --target=$(uname -m) kernel.spec
>
>We'd likely need to see the whole log. Also, why are you rebuilding
>something that is already built on koji? Normally that is done if
>someone makes modifications, so I'm curious if you have done so.
>
>josh
possibly unrelated:
I'm getting kernel panics when issuing legacy Fedora/Red Hat commands like and latest stable kernel in F22:
service network restart - kernel panic
Also with NetworkManager I get no kernel panics; however, it hoses my routing table when using a public VPN.
init 5 back to init 3 back to init 5 i lose display (but if I systemctl isolate graphical.target, multi-user.target...I do not lose display.
Maybe a document is needed for users to not use legacy tools?
Lance
>_______________________________________________
>kernel mailing list
>kernel(a)lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/kernel
8 years, 4 months
kernel panics 4.0.8-300.fc22.x86_64
by Lance Lassetter
I haven't debugged yet but I'm getting kernel panics on reboot of 4.0.8-300.
The machine is a 2008 manufactured Dell XPS 625 (one of the first Dell Alienware machines).
The OS is modified Fedora 22 server install.
Also when issued command
"init 5" then back "init 3" then back to "init 5" I get a black screen.
I'm mostly doing this to utilize firewall-config because IMHO firewall-cmd is just too cryptic when adding direct rules.
Also I attempted to unmask NetworkManager and it hosed my routing table. Would it be because I had NetworkManager-dispatcher active?
I know the latter two issues aren't kernel-related but might be or just as a side note.
Regards,
Lance Lassetter
8 years, 4 months
Building a custom kernel via cross compiling
by Andrew Wing
Hi all,
I am a newbie with kernel matters so I apologize in advance for what is a
newbie type setup question. My feeling is that if I send this query to the
more general Arm Fedora forum, the mere mention of kernel will provoke
glazed eyes :-)
The background is that I have an OEM board based on a TI AM3352 OMAP family
SoC looking somewhat like a Beaglebone black. Recently I've been exploring
getting this running under Fedora. In order to get it working I've cobbled
together the F22 minimal image along with a device tree blob created by a
colleague for this board, and a customised MLO/u-boot.
My next task is to look through and understand the arm kernel sources,
customize various aspects of the kernel config for my board and re-build.
It seems that instructions are here:
https://fedoraproject.org/wiki/Building_a_custom_kernel
However, I want to cross compile on a host system. To ease this process I
have set up a Fedora x86 box, also running f22, which is going to be the
host build machine.
I decided I should build from source rpm and was following the wiki
instructions(rpmdev-setuptree etc.) up to the point here...
*cd ~/rpmbuild/SPECS*
*rpmbuild -bp --target=$(uname -m) kernel.spec*
At this point I'd like to actually have a target of arm7l for my target but
entering this gets me an unknown target error (possibly not surprising
given the build machine/target architecture difference!).
My build machine does have a suitable linaro Arm compiler in place. It
occurs to me that I need a different kernel spec and to indicate to my
build system to use my compiler. Hopefully this can be achieved via some
slightly modified step from that given in the wiki page? Or should I be
tackling this in a completely different way?
Thanks in advance for any clarification.
regards,
Andrew
8 years, 4 months
Fedora kernel git tree and package maintenance
by Josh Boyer
Hi All,
The kernel team has been running an exploded git tree since Flock last
year. This has been mostly a "nice to have", but several people have
commented on how useful it is for them when debugging issues, etc.
Having the exploded sources with the patches we carry included lets
them easily see what we have changed and how.
While not a huge burden, this has been mostly an additional effort on
top of what we already do. In order to make us a bit more efficient,
we've been looking at ways to automate or ease this, as well as make
it possible for more than one person to maintain it. This has lead to
some discussion around moving to making the exploded git tree the
canonical source location for Fedora kernel work. I'm sending this
email to start a conversation around that.
So what would this mean? It means we'd maintain the exploded source
tree very similar to today, with it rebasing on top of whatever
upstream we're using as our base. For info on how that works, see the
blog post I did about that a while ago.
Using this exploded tree, I've created some scripts to generate the
pkg-git content. This is probably the biggest workflow change
involved. We still need to use pkg-git to do builds in koji, but
direct commits to that repo would be disabled outside of a few of us
needed to do the syncs. Patches and config changes could be done via
email to this list, or possibly via pull request to the branch
maintainer of the exploded tree.
Why would we do this? A few reasons. First, it allows us to
eliminate duplicate maintenance in multiple spots while still
providing all the same things we are right now. Second, it moves us
to more of an upstream kernel development model and hopefully
increases both visibility and communication in terms of what
patches/changes go in, etc. It also makes our job easier during
rebases, as we can literally use 'git rebase' and work via that
instead of having to copy around patches to different trees or
manually adjust patches outside of a normal git workflow.
Who does this impact? Honestly, not many. There are exactly 4 people
that commit to pkg-git today on anything resembling a regular basis.
However, it is my hope that changing the workflow a bit makes this
somewhat easier for others to work against a tree and submit patches
and changes. I'm not under any impressions that it will exponentially
increase our contributors, but it will quite possibly make things a
bit more transparent.
Is this a done decision? No. Not at all. In fact, the scripts
aren't even finished yet. I wanted to get the discussion started
before really investing heavily in finishing them off. Justin and
Laura have copies of the (unfinished) scripts and a howto document on
various tasks. I'll likely send the howto out once I get a few of the
last remaining steps working for people to read over. But the general
idea isn't going to change much, which is why we're talking about this
now.
When would this happen? Unclear. Certainly not this month as one of
the primary stakeholders is on PTO. If the discussion goes well and
this direction is something we're going to do, then it might be next
month or at some natural cut-over point.
Will the exploded tree go away if we don't change to this model? Also
unclear. I'd hesitantly say it would stick around, but it might
change in the way it is created and published.
I'm sure there will be more questions, so please ask away. Looking
forward to hearing other's thoughts.
josh
8 years, 5 months
kdbus and Fedora
by Josh Boyer
Hi All,
Harald and I were recently talking about kdbus and how it plays into
Fedora. Right now, the kernel-playground COPR is carrying the kdbus
patches, but that isn't widely used and isn't included in a broad test
base. Obviously our distribution is heavily entwined with D-Bus and we
were looking to see if it was possible to help kdbus testing and
development by doing some kind of integration within Fedora itself. I
promised Harald I would talk it over with the other Fedora kernel
maintainers and after a brief discussion we came up with the following
possible proposal.
If Fedora were to carry kdbus in any form, the following things would
be required:
1) There would be a single canonical location to track kdbus
development. After talking with Harald, that should be the upstream
tree that gregkh is using to submit patches.
2) Harald's team (systemd, etc) would commit to testing the system
both with and without kdbus active. Obviously we do not want to
enforce reliance on something as core critical as kdbus while it is
still being actively developed upstream. That could cause a lot of
deviation down the road and it isn't the aim here.
3) kdbus would only be carried in the rawhide branch until it is
merged upstream. As a concrete example, if kdbus was not merged in
the upstream kernel at the time rel-eng creates the F23 branches, then
Fedora 23 will never get kdbus. It will be carried in rawhide and
rawhide only until it's accepted upstream. The maintainers actually
hope this does get merged but we want to make sure we are prepared to
drop this without causing too much trouble if needed.
4) After discussing a bit with the rest of the Fedora kernel
maintainers, we would carry an additional patch that would require
'kdbus-enabled' to be specified before the kernel would allow kdbus to
be loaded (or similar mechanism). This would focus the main testing
effort for all the default images to remain as they are today, while
easily allowing the plumbing layer developers access to kdbus for
their enablement testing.
These conditions would hopefully help the Fedora kernel maintainers
avoid some of the pitfalls of carrying a large chunk of out of tree
code and if they're all met we feel fairly comfortable with doing
this. We wanted to send this out for a bit wider discussion and
review before proceeding with it, and I agreed to start this thread so
here we are.
Harald, does the above look like what you were envisioning when we
talked earlier?
josh
8 years, 5 months
experimental scripts for bisecting the kernel
by Laura Abbott
Hi all,
I expanded on some of the scripts that Josh wrote and came up with a set of
scripts to aid in bisecting the kernel project. The idea here is to replay the
Fedora patches on top of each step of a kernel bisect. Ultimately, I'd like to
have something to give to bugzilla reporters to be able to narrow down which
change caused their issue.
The scripts are in a repo at https://pagure.io/fedbisect (HTML readme didn't
come out well, the text version looks better)
If you want to play around with it:
git clone git@pagure.io:fedbisect.git
./setup-pkg-git.sh <name for your kernel subdirectory>
Wait for kernel tree to finish syncing
cd <subdir>/fedora
./fedbisect.sh start <good version> <bad version>
this will kick of a kernel build and make install a kernel. You can then do
./fedbisect.sh good
./fedbisect.sh bad
to indicate if a particular kernel is good or bad according to your tests.
These scripts are very experimental right now but go ahead and try them out
and report bugs (or give patches!).
Thanks,
Laura
8 years, 5 months
why are these drivers missing from the Fedora kernel?
by Ranjan Maitra
Hi,
I posted this earlier but did not get a response, so here's hoping that someone who notices has more suggestions.
I am a long-time Fedora user since Fedora Core 1 and I am looking at installing Fedora 22 on a MS Surface Pro 3 with Type Cover. But in order to do that (and to have the cover recognized), I noticed that the file linux-***/drivers/hid/hid-ids.h in the kernel from kernel.org is missing. This is however available at kcbench (which is the kernel compiled for benchmarking). I was wondering what the reasoning behind this is, because we can not have the Type Cover 3 recognized with the LiveCD while installing (and so installing without a keyboard is a major hassle). Not to mention, kcbench draws in over 500 MB with a dnf update.
Also, is this the correct arena for discussing linux-firmware? If not, I apologize. If it is, I was looking at:
/lib/firmware/mrvl
which is provided by the linux-firmware rpm and I noticed that it is missing some files:
This is what is in my updated files list:
pcie8897_uapsta.bin sd8797_uapsta.bin usb8766_uapsta.bin
sd8688.bin sd8887_uapsta.bin usb8797_uapsta.bin
sd8688_helper.bin sd8897_uapsta.bin usb8897_uapsta.bin
However, the list here (git://git.marvell.com/mwifiex-firmware.git) have some more -- here is thelist:
pcie8897_uapsta.bin sd8797_uapsta.bin usb8766_uapsta.bin*
sd8688.bin sd8801_uapsta.bin* usb8797_uapsta.bin
sd8688_helper.bin sd8887_uapsta.bin* usb8801_uapsta.bin*
sd8787_uapsta.bin sd8897_uapsta.bin usb8897_uapsta.bin
So, I was wondering: why are some of the files missing? Is it because of non-OSS issues? Or should I file a bug/feature request?
Many thanks,
Ranjan
____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/manager
8 years, 5 months