[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
7 years, 10 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
7 years, 10 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
7 years, 11 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
7 years, 11 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
7 years, 11 months
ppc64 kernel config changes heads up
by Peter Robinson
Hi All,
If you don't care about powerpc you can stop reading :-)
If you do.... I went to do what I thought was a basic fix up to the
kernel builds on POWER to get rid of the last bits of the ppc32
legacy, on my list for some time, and it has become more of a slightly
epic slash and burn!
The resulting output kernel configs are for all intents and purpose
unchanged but the git diff is some what epic.
The top level of the changes are:
Core changes that apply too all kernels (ppc64/ppc64p7/ppc64le) reside
in config-powerpc64-generic
config-powerpc64 -> legacy platforms that are older than POWER7 and
their dependencies (here lies the ghosts of PowerPC G5 and friends).
config-powerpc64le and config-powerpc64p7 contain anything specific to
POWER7 and newer that might affect older platforms, or LE/BE specific
to p7 and later
I've removed anything that pertains to PPC32 and Cell processors (the
later were all disabled now anyway) but if the kernel docs were wrong
and they do by chance work on some other 64 bit platform that still
works do let me know.
So the only thing of real note is the ppc64p7 and ppc64le configs no
longer have any old IDE configs enabled or any of the legacy Apple
bits pulled in, I don't believe that should cause any pain what so
ever, I only bring this up because it's the only thing of note on
diffs of before/after resulting config diffs.
So ultimately please test kernel builds going forward. There's a
scratch build here [1] until we get an official one to test. There's
no perf packages, that appears broeken... even on vanilla pre commit
:)
For those that are morbidly interested in the diff (and don't have the
Fedora kernel package check out) you can see that here [2].
Ultimately the large git commit looks quite scary but the actual
change to the 3 configs are minimal and I believe this should make
things cleaner moving forward :-)
I look forward to the testing feedback including any further suggested
cleanups to the new configs, oh and please test :-)
Peter
[1] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2582705
[2] http://pkgs.fedoraproject.org/cgit/kernel.git/commit/?id=c9229e16082bdc9b...
7 years, 11 months
Initial aarch64 config updates for 4.2
by Peter Robinson
Below are a few minor updates for aarch64 in 4.2, didn't want to send too many in fear of getting the process screwed up. Feedback welcomne :)
7 years, 11 months
Re: ppc64 kernel config changes heads up
by Peter Robinson
Alex,
> With all due respect, you do realize that several companies actually still manufacture and sell 32-bit PowerPC processors, correct? Do you think this move will be well-met by them?
With all due respect do you realise we actually dropped support for
"32-bit PowerPC processors" for all release post Fedora 20?
Fedora 20 went EOL this week but it was known when Fedora 20 went GA
in December of 2013, around 18 months ago, that ppc-32 was EOL. This
isn't a shock or unknown, it was widely publicised that that if people
were interested in 32 bit PPC in general that they needed to pick up
the architecture maintainership, and in fact the kernel hasn't had the
bits in place to build for ppc-32 for some time, in the ppc32 case
it's merely cleaning up the left over bits of something, in terms of
the Fedora kernel, that has long been dead.
Peter
>> On Jun 26, 2015, at 2:40 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>>
>> Hi All,
>>
>> If you don't care about powerpc you can stop reading :-)
>>
>> If you do.... I went to do what I thought was a basic fix up to the
>> kernel builds on POWER to get rid of the last bits of the ppc32
>> legacy, on my list for some time, and it has become more of a slightly
>> epic slash and burn!
>>
>> The resulting output kernel configs are for all intents and purpose
>> unchanged but the git diff is some what epic.
>>
>> The top level of the changes are:
>>
>> Core changes that apply too all kernels (ppc64/ppc64p7/ppc64le) reside
>> in config-powerpc64-generic
>>
>> config-powerpc64 -> legacy platforms that are older than POWER7 and
>> their dependencies (here lies the ghosts of PowerPC G5 and friends).
>>
>> config-powerpc64le and config-powerpc64p7 contain anything specific to
>> POWER7 and newer that might affect older platforms, or LE/BE specific
>> to p7 and later
>>
>> I've removed anything that pertains to PPC32 and Cell processors (the
>> later were all disabled now anyway) but if the kernel docs were wrong
>> and they do by chance work on some other 64 bit platform that still
>> works do let me know.
>>
>> So the only thing of real note is the ppc64p7 and ppc64le configs no
>> longer have any old IDE configs enabled or any of the legacy Apple
>> bits pulled in, I don't believe that should cause any pain what so
>> ever, I only bring this up because it's the only thing of note on
>> diffs of before/after resulting config diffs.
>>
>> So ultimately please test kernel builds going forward. There's a
>> scratch build here [1] until we get an official one to test. There's
>> no perf packages, that appears broeken... even on vanilla pre commit
>> :)
>>
>> For those that are morbidly interested in the diff (and don't have the
>> Fedora kernel package check out) you can see that here [2].
>>
>> Ultimately the large git commit looks quite scary but the actual
>> change to the 3 configs are minimal and I believe this should make
>> things cleaner moving forward :-)
>>
>> I look forward to the testing feedback including any further suggested
>> cleanups to the new configs, oh and please test :-)
>>
>> Peter
>>
>> [1] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2582705
>> [2] http://pkgs.fedoraproject.org/cgit/kernel.git/commit/?id=c9229e16082bdc9b...
>> _______________________________________________
>> ppc mailing list
>> ppc(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/ppc
>
7 years, 11 months
file hid-ids.h
by Ranjan Maitra
Hi,
I am a long-time Fedora user 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).
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
____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
7 years, 11 months
[PATCH] kernel-tests: modsign: Change keyring name and kernel module file name
by Masami Ichikawa
This patch changed keyring name and kernel module name to run modsign test
correctly.
Current kernel uses .system_keyring as keyring name so test code needs to use
key name .system_keyring instead of module_sign.
Fedora project provides kernel modules as xz archived format.
So, test code should extract a kernel module from an archive file.
---
default/modsign/modsign_tests.sh | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/default/modsign/modsign_tests.sh b/default/modsign/modsign_tests.sh
index b0bab67..63748ad 100755
--- a/default/modsign/modsign_tests.sh
+++ b/default/modsign/modsign_tests.sh
@@ -7,7 +7,7 @@ modsign_check_modules()
# Grab a module to mess around with. We'll pick one that is fairly
# stand-alone and rarely used.
- cp /lib/modules/`uname -r`/kernel/fs/minix/minix.ko .
+ xz -dc /lib/modules/`uname -r`/kernel/fs/minix/minix.ko.xz > minix.ko
# Make sure we have the signed module marker
cat ./minix.ko | strings | grep "~Module signature appended~" &> /dev/null
@@ -59,7 +59,7 @@ modsign_unsigned()
{
# Grab a module to mess around with. We'll pick one that is fairly
# stand-alone and rarely used.
- cp /lib/modules/`uname -r`/kernel/fs/minix/minix.ko .
+ xz -dc /lib/modules/`uname -r`/kernel/fs/minix/minix.ko.xz > minix.ko
strip -g ./minix.ko
# Make sure it isn't already loaded
@@ -109,13 +109,13 @@ modsign_third_party()
modsign=0
if [ -f /proc/keys ]
then
- cat /proc/keys | grep module_sign &> /dev/null
+ cat /proc/keys | grep .system_keyring &> /dev/null
if [ $? -ne "0" ]
then
echo Module signing not enabled
exit 3
fi
- keyring=`cat /proc/keys | grep module_sign | cut -f 1 -d " "`
+ keyring=`cat /proc/keys | grep .system_keyring | cut -f 1 -d " "`
keyctl list 0x${keyring} | grep "Fedora kernel signing key" &> /dev/null
if [ $? == "0" ]
then
--
2.4.3
7 years, 11 months