Since updating to F22 I don't seem to be able to attach strace or gdb to my own processes: [dwoodhou@i7 ~]$ strace -p `pidof firefox` strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted This occurs even with SELinux in permissive mode.
A temporary workaround is 'echo 0 > /proc/sys/kernel/yama/ptrace_scope'
This is how Yama is supposed to work. This is already the default in Ubuntu and ChromeOS. Developers can tweak /proc/sys/kernel/yama/ptrace_scope to weaken the ptrace restrictions as desired. Documentation/security/Yama.txt describes Yama and ptrace_scope further.
Output of the same command on Ubuntu is a bit more helpful: $ strace -p `pidof firefox` strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
(In reply to Stephen Smalley from comment #3) > Output of the same command on Ubuntu is a bit more helpful: > $ strace -p `pidof firefox` > strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted > Could not attach to process. If your uid matches the uid of the target > process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try > again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf That would be a *slightly* less obnoxious way to break a long-standing kernel ABI, certainly. Is there really no way we can make this work for the "normal" case of strace/gdb being invoked directly from a local terminal/xterm/emacs, without also allowing the problematic cases?
(In reply to David Woodhouse from comment #4) > That would be a *slightly* less obnoxious way to break a long-standing > kernel ABI, certainly. If we patched the strace error message would you consider this resolved? > Is there really no way we can make this work for the "normal" case of > strace/gdb being invoked directly from a local terminal/xterm/emacs, without > also allowing the problematic cases? How do you distinguish between a valid use case and a problem use case?
(In reply to Paul Moore from comment #5) > (In reply to David Woodhouse from comment #4) > > That would be a *slightly* less obnoxious way to break a long-standing > > kernel ABI, certainly. > > If we patched the strace error message would you consider this resolved? Perhaps. The error message should also be in gdb and other ptrace users too, of course. And it's a bit of a cop-out to say "if your uid matches the uid of the target process" when that can be verified in code. Likewise to say "check the setting of /proc/sys/kernel/yama/ptrace_scope" when that's world-readable too. But if that's fixed, and if this is addressing a genuine attack vector that's actually used in practice, and if we've exhausted the discussion below, then I suppose so. > > Is there really no way we can make this work for the "normal" case of > > strace/gdb being invoked directly from a local terminal/xterm/emacs, without > > also allowing the problematic cases? > > How do you distinguish between a valid use case and a problem use case? To be conservative, let's start by saying that the valid use cases we *really* want to enable easily are running strace or gdb directly from an interactive terminal. Although ideally stuff would also work automatically in emacs, eclipse, etc.. You could perhaps keep the kernel side simple by giving ptrace access to a specified *group* as well as the root user. Then we can have setgid wrappers for strace/gdb which do the appropriate filtering — dropping the additional group unless the criteria are met. Now we've reduced the problem to some privileged code in userspace deciding if it can meet our criteria.... whatever they are :) FWIW we already have the usermode helper which does something similar, and might be useful for inspiration. A first cut might be to say that access should be permitted if we are the process group leader on a real tty. Although an attacker could make a new pty and abuse that, so maybe we need a way to determine that a given pty is 'genuine', allowing a (non-ptraced) gnome-terminal, xterm or other terminal program to mark it as such. It's starting to look a little complex, but perhaps not insurmountable. And usermode does already do a bunch of similar stuff and could be extended. Is it worth continuing...?
(In reply to David Woodhouse from comment #6) > (In reply to Paul Moore from comment #5) > > (In reply to David Woodhouse from comment #4) > > > That would be a *slightly* less obnoxious way to break a long-standing > > > kernel ABI, certainly. > > > > If we patched the strace error message would you consider this resolved? > > Perhaps. The error message should also be in gdb and other ptrace users too, > of course. And it's a bit of a cop-out to say "if your uid matches the uid > of the target process" when that can be verified in code. Likewise to say > "check the setting of /proc/sys/kernel/yama/ptrace_scope" when that's > world-readable too. > > But if that's fixed, and if this is addressing a genuine attack vector > that's actually used in practice, and if we've exhausted the discussion > below, then I suppose so. Okay, let's punt on this part of the discussion for the moment.
(In reply to David Woodhouse from comment #6) > > How do you distinguish between a valid use case and a problem use case? > > To be conservative, let's start by saying that the valid use cases we > *really* want to enable easily are running strace or gdb directly from an > interactive terminal. Although ideally stuff would also work automatically > in emacs, eclipse, etc.. > > You could perhaps keep the kernel side simple by giving ptrace access to a > specified *group* as well as the root user. Then we can have setgid wrappers > for strace/gdb which do the appropriate filtering — dropping the additional > group unless the criteria are met. I've lost track, don't we have working file capabilities in Fedora now? Why not just grant CAP_SYS_PTRACE to these applications?
Yeah, we could use CAP_SYS_PTRACE instead of a group. It doesn't matter really. The important thing is that we don't want an attacker to just circumvent the ptrace protecton by spawning gdb and having gdb do its dirty work for it. You want the elevated permissions *only* when the debug tool in question is being spawned directly from an appropriate context.
Yama already permits the ptrace if the tracee is a descendant of the tracer, which is the normal situation when you start a program via gdb or strace. It just doesn't allow you to attach to unrelated processes. Also there is a way for programs to explicitly opt into tracing by another process, used by crash handlers. The first thing to fix IMHO is just to provide an easy way to configure ptrace_scope in a manner preserved across reboots, and update any userspace programs like strace to point the user to that facility, as apparently has already been done in Ubuntu. And make sure the change in default behavior is captured prominently in the release notes. That will cover most users just fine; developers will just set it once the first time they run into it and everyone else will just be fine as is. I wouldn't start chasing more complex ways of inferring whether it is ok to open up holes in the restrictions until after that, and only if there is sufficient demand. Any such technique is potentially at risk of being abused by malicious code just as easily as by the user.
(In reply to Stephen Smalley from comment #10) > The first thing to fix IMHO is just to provide an easy way to configure > ptrace_scope in a manner preserved across reboots, I assume this should work: echo kernel.yama.ptrace_scope=0 > /etc/sysctl.d/98-yama.conf
Created attachment 1012747 [details] /etc/sysctl.d/10-ptrace.conf from Ubuntu Here is the /etc/sysctl.d/10-ptrace.conf that ships in Ubuntu. Then programs like strace can just refer users to it...
Created attachment 1012760 [details] strace yama patch
Created attachment 1012762 [details] gdb yama patch
Thanks guys, I'm away right now but I'll deal with sorting out the patches when I return.
elfutils libdwfl based tools also rely on ptrace working normally. Given that libdwfl is a shared library that just provides functionality to get process state like threads and backtraces it cannot just add CAP_SYS_PTRACE. Could we make sure that the yama.ptrace_scope=0 by default so tools don't randomly break? For example eu-stack -p `pidof firefox` should just keep working without the user having to become root or change settings that only root can change.
This is likely to hit developers.
Reptyr also affected.
Posted a fix: https://lists.fedoraproject.org/pipermail/kernel/2015-June/005894.html
Hello, I develop SWT / Eclipse. This issue breaks gdb in Eclipse. I.e, you can't launch and debug a C app with an of-the-box Eclipse. (On the side, it's not obvious as why Eclipse won't start a debug session either as there aren't any error messages. I presume this will affect Eclipse CDT users). I can temporarily work around it with: sudo chmod +s /usr/bin/gdb But this I seem to have to do every time gdb get's updated. I updated my system ~20 mins ago (F22), but issue still occurs. Is the above patch already available for updates or will it take some time?
(In reply to Lev Ufimtsev from comment #20) > I updated my system ~20 mins ago (F22), but issue still occurs. > > Is the above patch already available for updates or will it take some time? The patch is ready and if you want I can provide scratch builds if you want to test it out. We are still discussing whether the fix should go into the kernel or systemd pacakge (see also bug #1234951).
(In reply to Mark Wielaard from comment #21) > (In reply to Lev Ufimtsev from comment #20) > > I updated my system ~20 mins ago (F22), but issue still occurs. > > > > Is the above patch already available for updates or will it take some time? > > The patch is ready and if you want I can provide scratch builds if you want > to test it out. We are still discussing whether the fix should go into the > kernel or systemd pacakge (see also bug #1234951). I don't know much about alpha/beta testing of fresh packages/kernel packages. That said I know my way around yum/dnf & repo management in general (RHCSA wise). If I'm given some instructions/guidelines on how to get the fix onto my system, then I'd be most happy to test the fix.
(In reply to Lev Ufimtsev from comment #22) > (In reply to Mark Wielaard from comment #21) > > (In reply to Lev Ufimtsev from comment #20) > > > I updated my system ~20 mins ago (F22), but issue still occurs. > > > > > > Is the above patch already available for updates or will it take some time? > > > > The patch is ready and if you want I can provide scratch builds if you want > > to test it out. We are still discussing whether the fix should go into the > > kernel or systemd pacakge (see also bug #1234951). > > I don't know much about alpha/beta testing of fresh packages/kernel > packages. That said I know my way around yum/dnf & repo management in > general (RHCSA wise). If I'm given some instructions/guidelines on how to > get the fix onto my system, then I'd be most happy to test the fix. I believe we have consensus that the fix should be in the systemd package, not in the kernel package. So I started a scratch build of a new systemd package for f22 with the fix applied: http://koji.fedoraproject.org/koji/taskinfo?taskID=10260385 Once that finishes successfully (links turn green) you should be able to install the rpms for your architecture to test it. It is a scratch build, so will disappear again after a couple of days. Note that we are still discussing (see bug #1234951) some details about wording and file paths, so the final fix might look slightly different. But feedback on whether or not this approach works for you would be appreciated.
(In reply to Mark Wielaard from comment #23) > So I started a scratch build of a new systemd > package for f22 with the fix applied: > http://koji.fedoraproject.org/koji/taskinfo?taskID=10260385 I downloaded & sudo dnf updated the newly build packages. Now permissions error doesn't come up anymore. Fix seems to work well.
Created attachment 1048821 [details] Revert to upstream CONFIG_SECURITY_YAMA default Looks like systemd maintainers don't want to carry sysctl files for the kernel. If the kernel also doesn't want to carry its own sysctl files (and we don't want to add fixes to all individual packages affected) it seems best to revert to the default upstream yama setting instead. Which is what this patch does. This fixes all applications relying on ptrace to working as expected.
Any ideas how to proceed?
I personally don't think reverting the Yama enablement is the right decision from a security perspective, ptrace can be a scary thing and restricting it is a Good Thing. However, I do recognize that this change has been a rude awakening to a few people, primarily developers. The systemd package does provide an example sysctl file, but it is an example file and not something that is enabled by default (the admin must move the file to the proper location). Stephen also posted a number of patches for various utilities to help provide more useful error messages. I think these are important and worth merging so long as we keep Yama enabled. This ultimately boils down to the same discussion we see a lot of time when new security controls are introduced that impact a use case: 1) how many people are affected, 2) what is the impact, and 3) how easy is the resolution. I think we understand #2, we've been discussing #3, but I'm not sure we have a good idea of #1 - how many people are truly affected. I'm likely a little biased, but I don't think the majority of Fedora users have been affected, although I do agree that there are a non-trivial number of users, primarily developers that are bumping into this change. I suggest we stick with the existing example sysctl file shipped as part of systemd, merge Stephen's improved error messages, and see where that takes us. If there are no objections within the next few days I'll create BZs for each of the individual packages with Stephen's patches attached. I'll also work with the Fedora package maintainers to get the patches merged.
I am providing an ABRT use case where we try to generate a backtrace from a process being dumped in order to avoid issues with removed libraries and so on. Generating backtrace in /proc/sys/kernel/core_pattern helper allows us to generate a meaningful backtrace without the need to have debuginfo available. This Yama configuration disables that ABRT feature and IMHO no useful error message can fix it. Would it be possible to always allow /usr/libexec/abrt-hook-ccpp to ptrace(PTRACE_ATTACH, ...)?
(In reply to Paul Moore from comment #27) > I personally don't think reverting the Yama enablement is the right decision I am afraid it is the only option now that neither the kernel nor systemd is able to install a sysctl file setting ptrace_scope=0. Without it user space is just broken and various packages installed will just not work giving a frustrating user experience. > from a security perspective, ptrace can be a scary thing and restricting it > is a Good Thing. Could you explain this a bit more. It has been argued before that it isn't really a security issue. ptrace is just a way processes use to communicate with each other. If they don't use ptrace they will use some other way which will have the same kind of restrictions. The example given is gnome-key-ring. Only when two processes are in the same user context can they exchange credentials and keys. They could also use ptrace for that to extract the information directly, but that works only when they already could query gnome-key-ring already. If they cannot, then they also cannot ptrace attach. Of course programs in different user/security context should be "protected" from interfering with each other. But they already are, so this seems just security theater, breaking stuff that shouldn't be broken. > However, I do recognize that this change has been a rude > awakening to a few people, primarily developers. As the various bug reports show not just developers. And any user should IMHO feel they can be a developer. If by developer you mean a user that wants know what the processes running on its behave are actually doing. Which I believe covers every user. We should encourage people from knowing why, what and how things run on their system and to encourage them to try to adapt things to their own needs. We should make it as easy as possible to be a developer. Not create some mythical "scary" developer stuff that can only be done safely by those knowing the magic incantations. > Stephen also posted a number of patches for various utilities to help > provide more useful error messages. I think these are important and worth > merging so long as we keep Yama enabled. I do think those patches would be useful in any case, so please do try to push them upstream. But they don't actually solve the problem. And it is a bit of a whack-a-mole because we don't even know the full scope of all the programs being broken at the moment. They don't even cover all the programs already reported broken, like eclipse, elfutils-libs, reptyr, abrt. > This ultimately boils down to the same discussion we see a lot of time when > new security controls are introduced that impact a use case: 1) how many > people are affected, 2) what is the impact, and 3) how easy is the > resolution. I don't think this is really similar. There is no step #3, no real resolution in this case. Except for packages to set the sysctl themselves on installation. Which might be what we end up with. But that really is just playing whack-a-mole. In other (real) security control discussions packagers are able to make sure the package as installed actually works. It might take some extra work. But they can make sure to give the executable the right permissions, create the right sandbox rights or craft the needed policy for the context in which the processes normally runs. In this case however, there is a question whether a) it actually is a security control or just breaks ABI for security theater. And b) there is just an all-or-nothing system-wide setting. You either have all user space kernel ABI broken or not. Adding obscure failure modes or printing errors in hard to discover logs is IMHO not a resolution.
(In reply to Jakub Filak from comment #28) > Would it be possible to always allow /usr/libexec/abrt-hook-ccpp to > ptrace(PTRACE_ATTACH, ...)? In theory assigning CAP_SYS_PTRACE to abrt-hook-ccpp would resolve the problem.
(In reply to Mark Wielaard from comment #29) > (In reply to Paul Moore from comment #27) > > from a security perspective, ptrace can be a scary thing and restricting it > > is a Good Thing. > > Could you explain this a bit more. I don't believe it is accurate to describe ptrace as simply another communication channel; the ability for one process to directly read and/or alter the state of another in way which ptrace provides goes far beyond simple communication. Everyone has a different threshold when it comes to "scary"; for me ptrace can be a scary thing, perhaps for you it is not. > > Stephen also posted a number of patches for various utilities to help > > provide more useful error messages. I think these are important and worth > > merging so long as we keep Yama enabled. > > I do think those patches would be useful in any case, so please do try to > push them upstream. But they don't actually solve the problem. And it is a > bit of a whack-a-mole because we don't even know the full scope of all the > programs being broken at the moment. They don't even cover all the programs > already reported broken, like eclipse, elfutils-libs, reptyr, abrt. If we are going to disable Yama in Fedora I see little value in spending the time/effort to merge the patches.
I don't understand much of the technicalities mentioned above, but breaking gdb's ability to attach to a process is quite a big thing imho. Tools that build on top of GDB (e.g Fedora Eclipse) will break and there is no information on why or how to fix it. I don't think having error messages is a good solution either, it should just work. One shouldn't have to flip 10 different switches to get a basic development environment working because this will discourage new developers from using Fedora. If it's a major security issue, then perhaps have "an option" to enable more security rather than break existing functionality by default.
(In reply to Paul Moore from comment #31) > Everyone has a different threshold when it comes to > "scary"; for me ptrace can be a scary thing, perhaps for you it is not. Agreed, ptrace is scary :) Powerful things often are. But lots of things are "scary". kill -9 is scary for example. Two processes running in the same user/security context can terminate each other using it. You can even send a signal to another process to dump core (if you have permission) and read that core to extract some memory contents from that process. That is as "scary" as ptrace is. But scary isn't a very accurate technical description, nor is it IMHO a good enough threat analysis to justify completely disalowing such interaction between processes (running in the same user/security context). > > I do think those patches would be useful in any case, so please do try to > > push them upstream. But they don't actually solve the problem. And it is a > > bit of a whack-a-mole because we don't even know the full scope of all the > > programs being broken at the moment. They don't even cover all the programs > > already reported broken, like eclipse, elfutils-libs, reptyr, abrt. > > If we are going to disable Yama in Fedora I see little value in spending the > time/effort to merge the patches. Fair enough. But it would be interesting to know what upstream thinks about them. Especially for the gui or deamon programs/libraries.
(In reply to Paul Moore from comment #30) > In theory assigning CAP_SYS_PTRACE to abrt-hook-ccpp would resolve the > problem. Note that assigning CAP_SYS_PTRACE to any program makes that program capable to ptrace any process without any restriction. So that does solve the issue, but in a very crude way. It raises the permissions above what a user would normally be able to do with the program (it is as if the program is setuid root wrt ptrace).
(In reply to Mark Wielaard from comment #34) > (In reply to Paul Moore from comment #30) > > In theory assigning CAP_SYS_PTRACE to abrt-hook-ccpp would resolve the > > problem. > > Note that assigning CAP_SYS_PTRACE to any program makes that program capable > to ptrace any process without any restriction. Thanks for the replies. It looks like that CAP_SYS_PTRACE is not necessary now as abrt-hook-ccpp runs under root privileges and ABRT tests passed successfully. I asked because we have seen several cases where we the ptrace() call failed, but that could be caused by something else.
(In reply to Mark Wielaard from comment #33) > Agreed, ptrace is scary :) Powerful things often are. > But lots of things are "scary". kill -9 is scary for example. > Two processes running in the same user/security context can terminate each > other using it. You can even send a signal to another process to dump core > (if you have permission) and read that core to extract some memory contents > from that process. That is as "scary" as ptrace is. But scary isn't a very > accurate technical description, nor is it IMHO a good enough threat analysis > to justify completely disalowing such interaction between processes (running > in the same user/security context). The Yama change does not completely disallow interaction between process, you know that. A more "accurate technical description" is that the new default Yama behavior restricts ptrace to those processes which are related, specifically only parents may ptrace() children, with the exception of those processes which have CAP_SYS_PTRACE. Further, do we really need to explain why it is bad/scary to allow one process to have almost complete control over another? For me personally, the fact that both processes live in the same security domain is of minimal comfort when one process is exploited and manages to gain access to the memory space of another. What secrets happen to live in the memory of the other process? Could the other process offer a different attack vector than the originally exploited process? In short, a successful PTRACE_ATTACH destroys breaks down the per-process memory separation which is one of the very fundamental pieces of Linux security.
(In reply to Paul Moore from comment #36) > A more "accurate technical description" is that the new > default Yama behavior restricts ptrace to those processes which are related, > specifically only parents may ptrace() children Yes, that behavior is precisely what breaks several applications :) Because those are the interesting uses of ptrace. Not being able to ptrace attach to one of your other processes, only direct children, is precisely why several packages don't work anymore. > with the exception of those processes which have CAP_SYS_PTRACE. I am not sure what CAP_SYS_PTRACE has to do with it. CAP_SYS_PTRACE gives setuid root capabilities to an executable. It also works with normal ptrace security restrictions. It allows a user to not only attach to their own processes, but to any processes. > Further, do we really need to explain why it is bad/scary to allow one > process to have almost complete control over another? Yes, I am afraid you have to :) You are proposing to break user space abi. Which as shown by all the broken programs and confused users is a pretty invasive thing. Just saying the it feels scary for you personally isn't enough. You must show that it really fixes a security issue and that it isn't just security theater, breaking stuff, but not providing any additional security. > In short, a successful PTRACE_ATTACH > destroys breaks down the per-process memory separation which is one of the > very fundamental pieces of Linux security. No, it is not. Processes running in the same user/security context can interact in various ways and read each others data easily. They can also read each others info on disk. Sent a signal to each other to cause core dumps and read those dumps, etc. And for example gnome-key-ring will trust that any processes in the same user/security context to handle authentication or passwords safely. You can create different selinux profiles for processes you don't want to freely interact or you can sandbox using seccomp if you want to "protect" processes running under the same user id from each other. But I don't believe yama ptrace scope adds anything to that.
(In reply to Mark Wielaard from comment #37) > (In reply to Paul Moore from comment #36) ... > > with the exception of those processes which have CAP_SYS_PTRACE. > > I am not sure what CAP_SYS_PTRACE has to do with it. CAP_SYS_PTRACE gives > setuid root capabilities to an executable. It also works with normal ptrace > security restrictions. It allows a user to not only attach to their own > processes, but to any processes. CAP_SYS_PTRACE does not give setuid root capabilities to an executable, it grants a process the ability to ptrace another. If you consider CAP_SYS_PTRACE functionally equivalent to marking an application setuid root then you should understand my concern. > > Further, do we really need to explain why it is bad/scary to allow one > > process to have almost complete control over another? > > Yes, I am afraid you have to :) Imagine process A, for the sake of argument let's say it is a password manager that reads an encrypted datastore from disk, decrypts it once you enter a password and stores the unencrypted data in memory while the program is running. Imagine process B, a simple command line tool that communicates over the network to perform some task (think wget, git, or something similar). Now, imagine you are running process both process A and B simultaneously, as the same user, in the same security domain, when process B is exploited and used to attack process A via ptrace. > > In short, a successful PTRACE_ATTACH destroys breaks down the per-process > > memory separation which is one of the very fundamental pieces of Linux > > security. > > No, it is not. Yes it does. There may be other mechanisms for one process to attack another, but that doesn't mean we shouldn't remove one potential attack vector.
> CAP_SYS_PTRACE does not give setuid root capabilities to an executable, it > grants a process the ability to ptrace another. To -any- other, including ones owned by root etc. Big difference. > [...] > Imagine process A, for the sake of argument let's say it is a password > manager that reads an encrypted datastore from disk, [...] True. > [...] There may be other mechanisms for one process to attack > another, but that doesn't mean we shouldn't remove one potential attack > vector. Maybe. If other equivalently-privileged vectors are known & available, they'll be exploited, and we are left only with the functionality loss, not the security gain.
(In reply to Frank Ch. Eigler from comment #39) > > CAP_SYS_PTRACE does not give setuid root capabilities to an executable, it > > grants a process the ability to ptrace another. > > To -any- other, including ones owned by root etc. Big difference. I understand the difference, but it isn't clear to me from his comments that Mark completely understands how this works. While you can make an argument that CAP_SYS_PTRACE is equivalent to setuid root, they are two different things and confusing them is not good. > > [...] There may be other mechanisms for one process to attack > > another, but that doesn't mean we shouldn't remove one potential attack > > vector. > > Maybe. If other equivalently-privileged vectors are known & available, > they'll be exploited, and we are left only with the functionality loss, not > the security gain. I'm reminded of one of my favorite quotes: "perfect is the enemy of good". I believe that any reduction in the number of attack vectors on a system is a desirable thing, even if other exist.
(In reply to Paul Moore from comment #38) > (In reply to Mark Wielaard from comment #37) > > (In reply to Paul Moore from comment #36) > > > with the exception of those processes which have CAP_SYS_PTRACE. > > > > I am not sure what CAP_SYS_PTRACE has to do with it. CAP_SYS_PTRACE gives > > setuid root capabilities to an executable. It also works with normal ptrace > > security restrictions. It allows a user to not only attach to their own > > processes, but to any processes. > > CAP_SYS_PTRACE does not give setuid root capabilities to an executable, it > grants a process the ability to ptrace another. If you consider > CAP_SYS_PTRACE functionally equivalent to marking an application setuid root > then you should understand my concern. CAP_SYS_PTRACE does give setuid root like capabilities, it allows the process to ptrace attach any other process, not just the ones running in the same user/security context. I am indeed concerned you bring it up because it might give package maintainers the impression they should just setcap cap_sys_ptrace=eip /usr/bin/gdb to solve the yama ptrace bug. But even without the yama bug this would be a very bad thing since it effectively removes any restrictions on ptrace, even the normal ones. > Imagine process A, for the sake of argument let's say it is a password > manager that reads an encrypted datastore from disk, decrypts it once you > enter a password and stores the unencrypted data in memory while the program > is running. Imagine process B, a simple command line tool that communicates > over the network to perform some task (think wget, git, or something > similar). > > Now, imagine you are running process both process A and B simultaneously, as > the same user, in the same security domain, when process B is exploited and > used to attack process A via ptrace. That is a good example. So you have a password manager, say gnome-keyring, that holds passwords and/or authentication keys on behave of other processes running in the same user/security context like above. Then removing any ptrace attach capability is to complete NOP. A process already in the same user/security context would just query the password manager like it normally would to get access to the passwords/authentication keys. Password managers like gnome-keyring are explicitly not designed to "protect" against processes that already should have access to the passwords. They even explicitly call this example out: "An example of security theater is giving the illusion that somehow one application running in a security context (such as your user session) can keep information from another application running in the same security context." https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy So if you are trying to guard against that, you must not run this password manager in the same user/security context as your network enabled command line utilities. Then they cannot get at the passwords/authentication keys (either directly or through ptrace). > There may be other mechanisms for one process to attack > another, but that doesn't mean we shouldn't remove one potential attack > vector. Sometimes hardening like this is a good thing, even if it doesn't really solve a direct security exploit. But only if the hardening actually makes things "harder" (and in this case the other ways to get at the data are much easier). And if the hardening doesn't cause major breakage and loss of normal functionality. Like in this case.
(In reply to Paul Moore from comment #40) > [...] While you can make an argument that CAP_SYS_PTRACE is equivalent to > setuid root, they are two different things and confusing them is not good. In terms of power, they are equivalent (setcap +CAP_SYS_PTRACED on /usr/bin/gdb is just as bad as setuid-root on /usr/bin/gdb). > I'm reminded of one of my favorite quotes: "perfect is the enemy of good". > I believe that any reduction in the number of attack vectors on a system is > a desirable thing, even if other exist. It is a cute enough quote, but unhelpful when in fact there are three choices (status quo, "good", "perfect"), and dispute about whether the status quo is good enough already. (See also "it ain't broken, don't fix it" and "KISS" for other cute quotes.)
(In reply to Paul Moore from comment #40) > I understand the difference, but it isn't clear to me from his comments that > Mark completely understands how this works. While you can make an argument > that CAP_SYS_PTRACE is equivalent to setuid root, they are two different > things and confusing them is not good. OK, lets drop this part. Trying to "score points" in knowing some obscure details better, or trying to using some terminology in a certain way than how the other person might have intended is not really constructive. My apologies. What we are looking for is unbreaking the packages that are currently broken by this bug. I think we can agree that using CAP_SYS_PTRACE is not the correct answer. Even if we disagree on everything else :)
FWIW, even without yama, you can't ptrace your own keyring: $ sysctl kernel.yama.ptrace_scope kernel.yama.ptrace_scope = 0 $ strace -p $(pgrep -u jistone gnome-keyring) strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
(In reply to Josh Stone from comment #44) > FWIW, even without yama, you can't ptrace your own keyring: > > $ sysctl kernel.yama.ptrace_scope > kernel.yama.ptrace_scope = 0 > $ strace -p $(pgrep -u jistone gnome-keyring) > strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted Yes, sorry, gnome-keyring isn't a good example since it doesn't really run in the same user/security context as normal processes. It runs with extended capabilities (I almost wanted to say setuid like, grin). In particular it uses cap_ipc_lock. And such processes (setuid or with extended capabilities) cannot be ptraced. The other often used example is ssh-agent, which uses prctl(PR_SET_DUMPABLE) to get the same effect. These examples might actually even be another reason why the yama.ptrace_scope thing is unnecessary in practice.
(In reply to Mark Wielaard from comment #41) > (In reply to Paul Moore from comment #38) > > Imagine process A, for the sake of argument let's say it is a password > > manager that reads an encrypted datastore from disk, decrypts it once you > > enter a password and stores the unencrypted data in memory while the program > > is running. Imagine process B, a simple command line tool that communicates > > over the network to perform some task (think wget, git, or something > > similar). > > > > Now, imagine you are running process both process A and B simultaneously, as > > the same user, in the same security domain, when process B is exploited and > > used to attack process A via ptrace. > > That is a good example. So you have a password manager, say gnome-keyring, > that holds passwords and/or authentication keys on behave of other processes > running in the same user/security context like above. Then removing any > ptrace attach capability is to complete NOP. A process already in the same > user/security context would just query the password manager like it normally > would to get access to the passwords/authentication keys. In my example I specifically did not describe a specific password manager because I didn't want to get caught up in any of the IPC mechanisms that particular application may support. Imagine a password manager, or some other application that holds secrets in the clear in memory.
(In reply to Paul Moore from comment #46) > In my example I specifically did not describe a specific password manager > because I didn't want to get caught up in any of the IPC mechanisms that > particular application may support. Imagine a password manager, or some > other application that holds secrets in the clear in memory. The specific IPC mechanism isn't the point. But this hand-waved hypothetical password manager must share its secrets somehow, and chances are the user is on that list of trusted people. Applications that are really paranoid can protect themselves, as gnome-keyring and ssh-agent do. I'm surprised to find that gpg-agent doesn't also. But then you have password managers like Thunderbird and Firefox, which are direct targets for exploits themselves, so ptrace blocking is moot anyway. I think the two sides of this debate are fairly entrenched, yet this decision has a distro-wide impact. Should this be raised to FESCo?
For a comparison, SELinux deny_ptrace went through the feature process: https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace I know dwalsh even wanted that turned on by default, but he backed down.
(In reply to Josh Stone from comment #47) > (In reply to Paul Moore from comment #46) > > In my example I specifically did not describe a specific password manager > > because I didn't want to get caught up in any of the IPC mechanisms that > > particular application may support. Imagine a password manager, or some > > other application that holds secrets in the clear in memory. > > The specific IPC mechanism isn't the point. But this hand-waved > hypothetical password manager must share its secrets somehow, and chances > are the user is on that list of trusted people. Right. > Applications that are really paranoid can protect themselves, as > gnome-keyring and ssh-agent do. I'm surprised to find that gpg-agent > doesn't also. And to show why the above matters in the case of gpg-agent it is obviously more practical to just call gpg-connect-agent than trying to exploit ptrace. In both the gnome-keyring and gpg-agent the disabling of ptrace is a side-effect of addresses a separate attack vector. gpg-agent also does care about not writing out any passwords or unencrypted keys to disk. So it does call rlimit to suppress writing out core files. One could argue that using the tricks from gnome-keyring and ssh-agent (using CAP_IPC_LOCK to lock memory so it doesn't get swapped out) and/or the calling prctl(PR_SET_DUMPABLE) to prevent any core file writing (not just the default kernel one, but also any other crash dumper that might ignore the rlimit) would be good additions https://bugs.gnupg.org/gnupg/issue1509 Both would have as side effect to also disable ptrace attach to the process (but ptrace isn't the main attach vector in this case and yama wouldn't prevent that either). > But then you have password managers like Thunderbird and > Firefox, which are direct targets for exploits themselves, so ptrace > blocking is moot anyway. ptrace blocking might be a good thing. But it depends on what the actual attack vector is whether or not it is something that addresses a real concern. Any examples given so far don't seem to actually "protect" against ptrace, but have some other attack vector that is much easier to exploit than through ptrace. Solving that actual attack vector by using priviliged separation or sandboxing the code will also solve any "attacks" through ptrace. Indiscriminately disabling ptrace through yama is just security theater.
(In reply to Josh Stone from comment #47) > I think the two sides of this debate are fairly entrenched, yet this > decision has a distro-wide impact. Should this be raised to FESCo? Please, for the love of $deity. When you do, please collect all of the bug reports in Fedora that were related to this issue. Or if you want bonus points, duplicate all of them here or treat this one as a tracker or something. As of right now, I know of exactly 1 bug report which would be this one. If others were pointed out to me, I've forgotten and I apologize for that. Collecting the data will help FESCo evaluate the scope of the issue here.
(In reply to Josh Stone from comment #47) > (In reply to Paul Moore from comment #46) > > In my example I specifically did not describe a specific password manager > > because I didn't want to get caught up in any of the IPC mechanisms that > > particular application may support. Imagine a password manager, or some > > other application that holds secrets in the clear in memory. > > The specific IPC mechanism isn't the point. But this hand-waved > hypothetical password manager must share its secrets somehow, and chances > are the user is on that list of trusted people. In retrospect the password manager wasn't the best choice because people are getting stuck on the idea that the application is going to share the data anyway so leaking it isn't a security risk (I would argue this, but that is another unrelated rathole). The password manager example was intended to demonstrate a class of applications which contain privileged secrets in memory that they aren't intended for sharing with other applications, regardless of the user and/or security domain.
(In reply to Josh Boyer from comment #50) > When you do, please collect all of the bug reports in Fedora that were > related to this issue. Or if you want bonus points, duplicate all of them > here or treat this one as a tracker or something. I submitted the Eclipse-CDT bug (Bug 1245759) that is caused by this security change. +1 to Mark Wielaard on the matter.
(In reply to Paul Moore from comment #51) > (In reply to Josh Stone from comment #47) > > (In reply to Paul Moore from comment #46) > > > In my example I specifically did not describe a specific password manager > > > because I didn't want to get caught up in any of the IPC mechanisms that > > > particular application may support. Imagine a password manager, or some > > > other application that holds secrets in the clear in memory. > > > > The specific IPC mechanism isn't the point. But this hand-waved > > hypothetical password manager must share its secrets somehow, and chances > > are the user is on that list of trusted people. > > In retrospect the password manager wasn't the best choice because people are > getting stuck on the idea that the application is going to share the data > anyway so leaking it isn't a security risk (I would argue this, but that is > another unrelated rathole). The password manager example was a good one since it is something practical and easy to reason about. Intuitively it feels like it might have a security issue because of ptrace, but on closer inspection the fact that the data is already shared (and if there is a security issue because that data is shared with other processes in the same user/security context) then that issue is unrelated to having ptrace or not. And ptrace will not even make things easier to collect the "secret" data. > The password manager example was intended to > demonstrate a class of applications which contain privileged secrets in > memory that they aren't intended for sharing with other applications, > regardless of the user and/or security domain. I am not sure what a better example there is than a password manager. Which program does keep data in memory that aren't eventually intended for some kind of output/sharing with other processes. The useful result of running a program is that there is output and someone will be using that output. But even if we just create that "output" as "secret data" in a process you can see that it doesn't really matter whether or not you have ptrace to extract it. Such data is only "secret" to other processes not in the same user/security context. Processes in the same user/security context (which is when ptrace normally works) also have access to the same input data as the other process. So they can just transform that input like the original program into the "secret data". They don't even have to guess how since they also have access to the other executable. And in practice it will of course be even easier because a program will create output based on those "secrets" that are the actually useful information, which you can then just directly access. So if you want to keep secret data in memory you better make sure to not run in a user/security context that shouldn't have access to it, so they cannot just reproduce it from accessing the same input data (or just access the output data you create). And when you do that then the normal ptrace security restrictions kick in and you also won't be able to ptrace that process anymore. So hopefully we have established that being able to ptrace attach to another process that runs in the same user/security context as another that isn't an (additional) security issue because there are easier ways to access the same inputs and output of that process then doing complicated tricks with ptrace. If you want to keep secrets you really should run in a separate context which automatically disallows ptrace already.
(In reply to Mark Wielaard from comment #53) > The password manager example was a good one since it is something practical > and easy to reason about. Intuitively it feels like it might have a security > issue because of ptrace, but on closer inspection the fact that the data is > already shared ... Of course you like the password manager example that you twisted from my original example so that it reinforces your own point of view. I'm not sure why that required another comment on this BZ. Neither of us are adding anything new to the conversation at this point; if you want to continue to contribute I suggest you heed Josh's suggestion in comment #50.
(In reply to Paul Moore from comment #54) > Of course you like the password manager example that you twisted from my > original example so that it reinforces your own point of view. I'm not sure > why that required another comment on this BZ. My apologies if I twisted the example, that was certainly not my intent. I am interested in fixing the bug, but also in understanding what the original intent of the change was it so we don't accidentally introduce any new regressions when it is fixed. Your and Josh examples of various cases really helped in the technical analysis. To me your original concrete and later abstract examples looked like separate cases that required separate analysis, which is why I did that twice. If you feel there are still technical issues that aren't analysed please let me know where you think the analysis was twisted and we can see if we can agree on the right technical interpretation. > Neither of us are adding anything new to the conversation at this point; if > you want to continue to contribute I suggest you heed Josh's suggestion in > comment #50. OK, if you think we have covered everything then lets summarize and get this issue finally resolved! I don't think FESCO needs to intervene while we are still constructively looking for solutions. But I do agree with Josh that next time a widely used user space interface is changed it might be good to bring it up with FESCO first. Please do augment my summary if anything is missing and which resolution is preferred. = Summary of the issue and affected packages and users: - With the current kernel package in f22 enabling yama the user can override the default security permissions for the ptrace system call. Normally a process can only ptrace attach to another processes when it runs in the same user/security context as the other process and it is able to manipulate the other process through sending signals. Depending on a new yama sysctl ptrace can be partially or fully disabled to work. - Without setting a default yama ptrace_scope sysctl value, yama will use a setting that prevents most uses of ptrace (a process can only ptrace attach to a direct child in the same user/security context). This will cause most code that uses ptrace to get a low-level error and break or fall back to less efficient or less capable code. - Since ptrace is used for various different interprocess communications this impacts very different users and use cases. Examples are screen utilities like reptyr, libraries like elfutils-libs and all programs depending on it, GUI programs like eclipse, daemons like abrt must run as root and cannot drop privileges to the user context in which ptrace normally would work and various developer tools like ltrace and valgrind that users use to observe their system stop working. - Unfortunately in most cases the error messages that a user gets (if any) are obscure and users have a hard time discovering why their system is broken. This causes users to turn off selinux and/or run their programs as root causing security issues (and might not actually unbreak their system). = Intent and effectiveness of the original change: - The original intent of the change in kernel config default for yama (see bug #1196825) was to provide the yama ptrace_scope sysctl. It isn't immediately clear whether the intent also was to set this sysctl to restricted ptrace or that just happened because if no default value is given for ptrace_scope it uses a setting of 1. But assuming it was then it was intended as security or hardening setting. - It is unclear whether this really does provide more security or whether it provides any effective hardening. It does mostly look like security theatre giving a false sense of preventing something that isn't actually a security issue or attack vector. Given the default ptrace security restrictions a process can only ptrace attach to another process if the process is in the same user/security context, has access to the same inputs and outputs as the other process and can already interact and manipulate the other process through other ipc mechanisms. So such processes cannot keep secrets from each other in the first place (see comment #53). It also doesn't make it harder to get at information from another process. In practice there are other information channels between processes running in the same user/security context that are a lot easier to use than ptrace (see comment #41 and comment #47). - The only real way to isolate data between processes is to run them in separate user/security context. If the threat is "spilling data" to disk then there are also other mechanisms like memory pinning with mlock/CAP_IPC_LOCK) or core dump prevention with PR_SET_DUMPABLE (see comment #49). All these mechanisms also prevent ptrace attach in the default security model. But that doesn't mean the other way around that if ptrace attach is disabled those other protections are enabled. = Proposed solutions: - Keep things as they are, but add some patches to some programs to make it more discoverable why the system is broken. There are only patches for 2 packages affected (gdb and strace) which haven't yet been pushed to the package maintainers nor to upstream. So it isn't clear whether they really are effective, acceptable to upstream and no ideas yet on how to fix all other utilities, libraries, guis and tools. So this would only works for command line utilities and still leaves the user system broken by default. - Keep YAMA enabled, but explicitly set the default value for the ptrace_scope sysctl to zero. This would still make it able for administrators to use extra yama restrictions, but unbreak the system by default. Patches were developed and scratch builds were made and tested for this solution for both the kernel and the systemd package (see bug #1234951). But neither the kernel maintainers not the systemd maintainers wanted to ship a sysctl file that did this. - Revert YAMA to the upstream kernel default (not set). The disadvantage of this change would be that an administrator cannot enable extra yama restrictions easily anymore. (See attachment #4 [details]). This patch is currently being discussed on the fedora kernel list. - Make each package that needs the default ptrace security settings to work explicitly set the yama ptrace_scope sysctl to zero as described in the Fedora Packaging Guidelines 5.18 to make sure the package isn't installed in a broken state. There is no patch for this yet. It has only been discussed between some of the affected package maintainers and could be done by having one small sub-package that everybody depends on. The disadvantages are that it is a bit of a whack-a-mole involving ~10 packages so needs a lot more coordination than fixing it in the kernel package and that the sysctl value will depend on which packages a user has installed.
(In reply to Mark Wielaard from comment #55) > My apologies if I twisted the example, that was certainly not my intent. I > am interested in fixing the bug, but also in understanding what the original > intent of the change was it so we don't accidentally introduce any new > regressions when it is fixed. Your and Josh examples of various cases really > helped in the technical analysis. There is a fundamental difference between how we each view this issue, and based on the fact that this will be comment #56 (or greater) I'm not expecting us to reach agreement. I believe that separation between processes, even processes running in the same security domain, is critical to system security. From what I've gathered based on your comments, you feel that separation between processes that share the same security domain is not important; usability is your primary motivation. > OK, if you think we have covered everything then lets summarize and get this > issue finally resolved! I don't think FESCO needs to intervene while we are > still constructively looking for solutions. But I do agree with Josh that > next time a widely used user space interface is changed it might be good to > bring it up with FESCO first. Please do augment my summary if anything is > missing and which resolution is preferred. I'm not sure we're doing anything "constructively" at this point. All we are doing is rehashing the same positions at this point; if you want to summarize the discussion, I agree there is some value in that, but I doubt we're going to see anything new. > = Summary of the issue and affected packages and users: ... > - Without setting a default yama ptrace_scope sysctl value, yama will use a > setting that prevents most uses of ptrace (a process can only ptrace attach > to a direct child in the same user/security context). This will cause most > code that uses ptrace to get a low-level error and break or fall back to less > efficient or less capable code. Let's drop the subjective analysis and describe exactly the Yama setting currently in use, as taken from the kernel documentation: "restricted ptrace: a process must have a predefined relationship with the inferior it wants to call PTRACE_ATTACH on. By default, this relationship is that of only its descendants when the above classic criteria is also met. To change the relationship, an inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare an allowed debugger PID to call PTRACE_ATTACH on the inferior. Using PTRACE_TRACEME is unchanged." > - Since ptrace is used for various different interprocess communications this > impacts very different users and use cases. Examples are screen utilities > like reptyr, libraries like elfutils-libs and all programs depending on it, > GUI programs like eclipse, daemons like abrt must run as root and cannot > drop privileges to the user context in which ptrace normally would work and > various developer tools like ltrace and valgrind that users use to observe > their system stop working. The abrt tool is now working, see comment #35. As for the other issues you mention above, I only see one other linked BZ at this point relating to Eclipse (are there more that you haven't linked, if so, why not? see comment #50). > = Intent and effectiveness of the original change: > - The original intent of the change in kernel config default for yama (see > bug #1196825) was to provide the yama ptrace_scope sysctl. It isn't > immediately clear whether the intent also was to set this sysctl to restricted > ptrace or that just happened because if no default value is given for > ptrace_scope it uses a setting of 1. But assuming it was then it was intended > as security or hardening setting. The intent was a value of 1/"restricted ptrace". > - It is unclear whether this really does provide more security or whether it > provides any effective hardening. Perhaps one of the more surprising things to me in this thread is that we have to argue about the value of enforcing separation between two process. For whatever reason you keep twisting my password database example so that it fits your argument, so here are a few more taken from the kernel documentation: "This is not a theoretical problem. SSH session hijacking (http://www.storm.net.nz/projects/7) and arbitrary code injection (http://c-skills.blogspot.com/2007/05/injectso.html) attacks already exist and remain possible if ptrace is allowed to operate as before. Since ptrace is not commonly used by non-developers and non-admins, system builders should be allowed the option to disable this debugging system." Note that the www.storm.net.nz site appears down but if you search for "SSH-Jack" you will find the code and presentations (see BlackHat); the same goes for the code injection attack (search "injectso").
Has anyone looked to see how Ubuntu handled things like the Eclipse breakage? Yama has been enabled by default in Ubuntu since Ubuntu 10.10, so they must have encountered all of these issues previously. However, given that Yama is apparently causing breakage for multiple packages, that we do not have in hand fixes for all of them or fully understand the scope of the impact, that neither the kernel nor systemd maintainers seem to want to carry a sysctl file for it (for reasons I do not entirely understand), and that this wasn't all addressed before release, I can see the argument for reverting in F22 (and F23?) and then reconsidering after userspace fixes are in place. My apologies for creating this firestorm; I had simply noted the absence of Yama in Fedora vs Ubuntu, thought it odd/unfortunate that Fedora would lack a security hardening that had been enabled in Ubuntu for years, and wrongly presumed that Ubuntu would have upstreamed userspace fixes for the associated issues by now.
(In reply to Paul Moore from comment #56) > (In reply to Mark Wielaard from comment #55) > > I am interested in fixing the bug, but also in understanding what the original > > intent of the change was it so we don't accidentally introduce any new > > regressions when it is fixed. Your and Josh examples of various cases really > > helped in the technical analysis. > > There is a fundamental difference between how we each view this issue, and > based on the fact that this will be comment #56 (or greater) I'm not > expecting us to reach agreement. I still hope we can at least agree on the technical aspects. > I believe that separation between > processes, even processes running in the same security domain, is critical > to system security. From what I've gathered based on your comments, you > feel that separation between processes that share the same security domain > is not important; usability is your primary motivation. I do believe usability is very important for effective security. I certainly don't think security isn't important. But separation between processes that share the same security domain is indeed not possible. But that has nothing to do with whether or not you enable ptrace. I hope our discussion at least showed different approaches to have both effective security by real separation and good usability giving people the ability to easily observe what their own processes do. Which I do indeed think is important for security because without it you just have to trust the binaries you are running do what they are supposed to do. > I'm not sure we're doing anything "constructively" at this point. All we > are doing is rehashing the same positions at this point; if you want to > summarize the discussion, I agree there is some value in that, but I doubt > we're going to see anything new. I am glad you value the summary. Lets agree that everything has been said. Next lets focus on the proposed solutions to move forward. > > - Without setting a default yama ptrace_scope sysctl value, yama will use a > > setting that prevents most uses of ptrace (a process can only ptrace attach > > to a direct child in the same user/security context). This will cause most > > code that uses ptrace to get a low-level error and break or fall back to less > > efficient or less capable code. > > Let's drop the subjective analysis and describe exactly the Yama setting > currently in use, as taken from the kernel documentation: > > "restricted ptrace: a process must have a predefined relationship with the > inferior it wants to call PTRACE_ATTACH on. By default, this relationship is > that of only its descendants when the above classic criteria is also met. To > change the relationship, an inferior can call prctl(PR_SET_PTRACER, > debugger, ...) to declare > an allowed debugger PID to call PTRACE_ATTACH on the inferior. Using > PTRACE_TRACEME is unchanged." I think that says the same thing as the summary said, just in more words and without mentioning what doesn't work. Just listing what does work isn't really helpful since the bug report is about all the use cases of packages that are currently broken because they don't fall into the above category. > The abrt tool is now working, see comment #35. It is only working because it must now run as root, unable to drop priviliges. It is an example how not being able to use ptrace in unpriviliged context is an additional security threat. abrt has seen multiple security issues lately. It really should be able to drop priviliges. > As for the other issues you > mention above, I only see one other linked BZ at this point relating to > Eclipse (are there more that you haven't linked, if so, why not? see > comment #50). Since we are encouraging people to add to this bug all the examples have been reported as comments to this bug. It is not just all discussion, half of the comments are people reporting broken applications and/or suggesting workaround or patches to fix things). I have verified they are all broken. Since there is simply one root cause it doesn't really make sense to open multiple bug reports if we can just fix them all by fixing this master bug. > > - It is unclear whether this really does provide more security or whether it > > provides any effective hardening. > > Perhaps one of the more surprising things to me in this thread is that we > have to argue about the value of enforcing separation between two process. > For whatever reason you keep twisting my password database example so that > it fits your argument I don't think it is surprising people ask for whether this is addressing a genuine attack vector that's actually used in practice. You are proposing to break a long standing kernel ABI. There should be a clear advantage if you want to do that. Not just security theater. You keep saying I am twisting your examples, but don't say how. I spend a lot of time providing technical analysis of your examples and providing practical solutions to the actual security issues identified. Others that have commented seem to agree with my analysis. > so here are a few more taken from the kernel > documentation: > > "This is not a theoretical problem. SSH session hijacking > (http://www.storm.net.nz/projects/7) and arbitrary code injection > (http://c-skills.blogspot.com/2007/05/injectso.html) attacks already exist > and remain possible if ptrace is allowed to operate as before. Since ptrace > is not commonly used by non-developers and non-admins, system builders > should be allowed the option to disable this debugging system." Note that the next sentence explains that a solution to this is to prevent dumping the process memory. Which also disables being able to ptrace the process. But just disabling ptrace isn't enough as has been explained before. > Note that the www.storm.net.nz site appears down but if you search for > "SSH-Jack" you will find the code and presentations (see BlackHat); the same > goes for the code injection attack (search "injectso"). Found it. The presentation does show various ways to exploit an ssh session once you have access to the user account (or root) for cross host privilige escalation using transient and non-transient trust between the hosts. You can get the authentication credentials, do key logging, mitm/tcp hijack the session, or hijack the ssh process itself. It does use ptrace through python scripting of gdb to trick openssh into create a new session to the remote system without disturbing any existing connections. That last possibility relies on using openssh 3.x on RH9 (yes, that old and it doesn't work anymore). Injectso is a nice idea, it works through hot-patching the code without needing to restart the application. They don't present it as an attack. As the presentation says you can use it to "Protect running services Kill bad input data as it comes in Intercept input functions and purify". The same is done by dyninst, which is packaged for fedora, and can be used with systemtap to apply security patches on the fly.
(In reply to Stephen Smalley from comment #57) > Has anyone looked to see how Ubuntu handled things like the Eclipse > breakage? Yama has been enabled by default in Ubuntu since Ubuntu 10.10, so > they must have encountered all of these issues previously. As far as I can tell things are just left broken. And everybody just disables yama as soon as they hit issues and someone explains how to unbreak their system. That is at least my experience with elfutils upstream. Every release someone running on ubuntu complains the testsuite is broken on their system. That is also how I noticed this bug first. I upgraded a machine and suddenly the testsuite wasn't zero-fail anymore. We did add some workaround to the testsuite that detect the setup is broken, but that just marks various tests as SKIPPED which isn't a real solution. > However, given that Yama is apparently causing breakage for multiple > packages, that we do not have in hand fixes for all of them or fully > understand the scope of the impact, that neither the kernel nor systemd > maintainers seem to want to carry a sysctl file for it (for reasons I do not > entirely understand), and that this wasn't all addressed before release, I > can see the argument for reverting in F22 (and F23?) and then reconsidering > after userspace fixes are in place. Agreed, lets revert for now. > My apologies for creating this firestorm; I had simply noted the absence of > Yama in Fedora vs Ubuntu, thought it odd/unfortunate that Fedora would lack > a security hardening that had been enabled in Ubuntu for years, and wrongly > presumed that Ubuntu would have upstreamed userspace fixes for the > associated issues by now. Emulating Ubuntu is not always the right approach :)
(In reply to Paul Moore from comment #56) > (In reply to Mark Wielaard from comment #55) > > - Since ptrace is used for various different interprocess communications this > > impacts very different users and use cases. Examples are screen utilities > > like reptyr, libraries like elfutils-libs and all programs depending on it, > > GUI programs like eclipse, daemons like abrt must run as root and cannot > > drop privileges to the user context in which ptrace normally would work and > > various developer tools like ltrace and valgrind that users use to observe > > their system stop working. > > The abrt tool is now working, see comment #35. As for the other issues you > mention above, I only see one other linked BZ at this point relating to > Eclipse (are there more that you haven't linked, if so, why not? see > comment #50). I fail to understand how "working" can be used in this situation. As Mark already explained, making ABRT run as root can hardly be considered a solution for this specific problem, especially when you seem to be spending a considerable amount of time and effort to make this "new behavior" look like a "security improvement". As a GDB developer, I would like to reinforce Mark's point by saying this decision should be reverted, at least for now.
BTW, in case it's not obvious, this isn't *just* about the ptrace syscall. Yama will filter anything that checks PTRACE_MODE_ATTACH in the kernel. That includes /proc/PID/{mem,personality,stack,syscall}, and also the syscalls process_vm_readv and process_vm_writev. These are probably all equally "scary" from a security standpoint, but they're not necessarily just for debugger-like tools. The manpage of the latter two says: "These system calls were designed to permit fast message passing by allowing messages to be exchanged with a single copy operation (rather than the double copy that would be required when using, for example, shared memory or pipes)." (but I'll grant that I don't know of anything using them this way)
Created attachment 1057920 [details] yama-kconfig_ptrace_default I just posted this patch to the LSM list as well as Kees, for some reason I'm not seeing it yet in the MARC archives so no link to share at the moment; consider it an exercise for the reader. Beyond that, I'm tired of arguing for ptrace_scope > 0 and I suspect you all are tired of arguing the opposite. We simply don't agree and that isn't going to change anytime soon; Mark, you've got more voices on your side so I'll concede. I'll work with Kees to make sure that this patch, or a similar solution, gets merged upstream. I would suggest using this new Kconfig knob to leave Yama enabled but with a default ptrace_scope of 0.
re [comment 18]: FYI: https://github.com/nelhage/reptyr/issues/59
Thanks Paul, Yama present with default ptrace_scope of 0 sounds fine. (similar to the sebool deny_ptrace, defaults off)
In the interest of the dependent Eclipse Bug. When/how can I test the newest patch to verify Eclipse's functionality with gdb remote attach again?
Lev, can you just run "sudo sysctl kernel.yama.ptrace_scope=0" for testing? The patch only makes it possible to set this state by default. As for tracking the patch, I can't find any public archive of the LSM list since June 19 or so. Did it go private? Even vger lists no archive links: http://vger.kernel.org/vger-lists.html#linux-security-module
(In reply to Paul Moore from comment #62) > Created attachment 1057920 [details] > yama-kconfig_ptrace_default > > I just posted this patch to the LSM list as well as Kees, for some reason > I'm not seeing it yet in the MARC archives so no link to share at the > moment; consider it an exercise for the reader. I must admit this reader is failing the exercise. Like Josh I am unable to find the list. Sorry. > I'll work with Kees to make sure that this patch, or a > similar solution, gets merged upstream. I would suggest using this new > Kconfig knob to leave Yama enabled but with a default ptrace_scope of 0. Thanks. I used the patch like you suggested and posted patches for the fedora kernels to the mailinglist: https://lists.fedoraproject.org/pipermail/kernel/2015-August/005962.html (In reply to Lev Ufimtsev from comment #65) > In the interest of the dependent Eclipse Bug. When/how can I test the newest > patch to verify Eclipse's functionality with gdb remote attach again? I am doing a scratch build of the kernel with the patch applied: http://koji.fedoraproject.org/koji/taskinfo?taskID=10572667 once that finishes you should be able to test that kernel by installing the right packages for your architecture. But note that since it is a scratch build it will be cleaned up after a couple of days).
(In reply to Josh Stone from comment #66) > As for tracking the patch, I can't find any public archive of the LSM list > since June 19 or so. Did it go private? Even vger lists no archive links: > http://vger.kernel.org/vger-lists.html#linux-security-module Something is a little odd with the LSM list, I'm not sure what. I probably need to contact the postmaster.
While Kees likes the idea of the patch, he has gotten push back in the past when trying to set sysctl defaults with CONFIGs. We need to find another fix. I think our next best option is to create a new package, e.g. yama-config-disable or similar, that delivers the necessary sysctl.d file with a ptrace_scope value of 0. Applications such as gdb, and others that might want unrestricted ptrace(), can set a dependency on the new yama-config-disable package. In some ways this has some nice advantages over the kernel based approach: self-documenting, dynamic based on package selection, etc. What do folks think, would this also be acceptable?
(In reply to Paul Moore from comment #69) > I think our next best option is to create a new package, e.g. > yama-config-disable or similar, that delivers the necessary sysctl.d file > with a ptrace_scope value of 0. Applications such as gdb, and others that > might want unrestricted ptrace(), can set a dependency on the new > yama-config-disable package. In some ways this has some nice advantages > over the kernel based approach: self-documenting, dynamic based on package > selection, etc. > > What do folks think, would this also be acceptable? Sure, that is a good idea. It is a bit like option 4 under proposed solutions in comment #55. Something like it was discussed between some of the package maintainers already if everything else would fail. So I think at least some would agree with it. Since I maintain elfutils I can add such a small package and make at least the subpackage that require it depend on it. Then we "just" need to file bugs against at least the packages mentioned in this bug report to add their own Requires. The other downside that was mentioned is that then the sysctl value will depend on which packages a user has installed. But I guess we just have to live with that for now.
(In reply to Paul Moore from comment #69) > I think our next best option is to create a new package, e.g. > yama-config-disable or similar, that delivers the necessary sysctl.d file > with a ptrace_scope value of 0. Applications such as gdb, and others that > might want unrestricted ptrace(), can set a dependency on the new > yama-config-disable package. In some ways this has some nice advantages > over the kernel based approach: self-documenting, dynamic based on package > selection, etc. > > What do folks think, would this also be acceptable? I think that would be acceptable for GDB, yes. As Mark mentioned, we have discussed this option last week just in case. I will contact the other team members about this decision, but I can push a fix for the GDB package as soon as we have the new package ready.
(One can imagine an RPM patch that scans a package's binaries for any call to ptrace(2), and if so, inserts a "Requires: syscall(ptrace)". Our hypothetical package would provide that via the sysctl.d file.)
> What do folks think, would this also be acceptable? Certainly better than the alternative of disabling yama protection totally.
Three quick comments: #1 - I think the package name "default-yama-scope" is misleading. The default Yama ptrace_scope setting is 1 (restricted-ptrace), not 0. We don't have to use "yama-config-disable", but I strongly believe we should use a package name that makes it very clear that the Yama protections are being disabled. #2 - I think this new sysctl package should be a new package and not defined as part of the elfutils, or any other, specfile. I'll create a new package later today and go through the new package submission process. #3 - We shouldn't automatically require this new package based only on the presence of the ptrace() syscall as not every ptrace attach event is affected.
(In reply to Paul Moore from comment #74) > #1 - I think the package name "default-yama-scope" is misleading. The > default Yama ptrace_scope setting is 1 (restricted-ptrace), not 0. We don't > have to use "yama-config-disable", but I strongly believe we should use a > package name that makes it very clear that the Yama protections are being > disabled. The idea is that it provides the default attach security permissions (the default that the system would normally have, as opposed to the extra restricted or admin-only settings). And the can use the config file to set the default they want (being a config file the default isn't overridden once the user changes it). > #2 - I think this new sysctl package should be a new package and not defined > as part of the elfutils, or any other, specfile. I'll create a new package > later today and go through the new package submission process. I don't think that is necessary. It could also have been part of the kernel or systemd (which made a bit more sense to me which is why I provided patches for those too earlier). The only thing that really matters is that packages add a Requires: default-yama-scope to their spec in case it is needed. Which concrete packages actually does the Provides: default-yama-scope doesn't really matter. I already did the work and the package is ready and in rawhide. I'll backport to f22 once it has seen a bit more testing. > #3 - We shouldn't automatically require this new package based only on the > presence of the ptrace() syscall as not every ptrace attach event is > affected. Yeah, this doesn't really only affect the ptrace syscall. And I don't actually know how to catch all syscalls a package could do in a simple way that would automate that. I think maintainers just have to add the Requires: default-yama-scope by hand.
(In reply to Mark Wielaard from comment #75) > (In reply to Paul Moore from comment #74) > > #1 - I think the package name "default-yama-scope" is misleading. The > > default Yama ptrace_scope setting is 1 (restricted-ptrace), not 0. We don't > > have to use "yama-config-disable", but I strongly believe we should use a > > package name that makes it very clear that the Yama protections are being > > disabled. > > The idea is that it provides the default attach security permissions (the > default that the system would normally have, as opposed to the extra > restricted or admin-only settings). And the can use the config file to set > the default they want (being a config file the default isn't overridden once > the user changes it). You didn't name the package "default-linux-scope", you named it "default-yama-scope". As discussed the value in the inside the sysctl file is not the default yama setting and there is little in the package name to indicate ptrace is involved. I've created a new package, "yama-config-disable-ptrace" (I'll attach it as soon as I hit reply here), which I think makes it very clear what the package is doing just from the name. > > #2 - I think this new sysctl package should be a new package and not defined > > as part of the elfutils, or any other, specfile. I'll create a new package > > later today and go through the new package submission process. > > I don't think that is necessary. It could also have been part of the kernel > or systemd (which made a bit more sense to me which is why I provided > patches for those too earlier). The only thing that really matters is that > packages add a Requires: default-yama-scope to their spec in case it is > needed. Which concrete packages actually does the Provides: > default-yama-scope doesn't really matter. I already did the work and the > package is ready and in rawhide. I'll backport to f22 once it has seen a bit > more testing. I strongly disagree, I think it is very important that this package is standalone so that it is not associated with a particular package. While I agree that it would have been better to ship the sysctl with the kernel, or perhaps even the systemd package, but that isn't an option anymore. > > #3 - We shouldn't automatically require this new package based only on the > > presence of the ptrace() syscall as not every ptrace attach event is > > affected. > > Yeah, this doesn't really only affect the ptrace syscall. And I don't > actually know how to catch all syscalls a package could do in a simple way > that would automate that. I think maintainers just have to add the Requires: > default-yama-scope by hand. Well, at least we agree on one thing. That's a first.
Created attachment 1059168 [details] yama-config-disable-ptrace-1-0.fc24.src.rpm
Paul, it turns out we don't need unanimity on the name of the RPM; the client RPMs can decide separately on what option suits them. Heck, they could include their own sysctl.d files. (FWIW on the toolshedding front, the "yama-config-disable-ptrace" package re-enables rather than disables ptrace. FWIW I can't think of any material differences to a fedora user or developer as regards the origins of the .noarch.rpm carrying the sysctl.d file, whether a subrpm of elfutils.src.rpm, or kernel.src.rpm, or anythingelse.src.rpm.)
The new package request: RHBZ #1250179
(In reply to Frank Ch. Eigler from comment #78) > Paul, it turns out we don't need unanimity on the name of the RPM; the > client RPMs can decide separately on what option suits them. Heck, they > could include their own sysctl.d files. If we don't agree on a common package name, or provides token, then how would the dependency work? As far as each package shipping their own sysctl file, I think we can all agree that wouldn't be preferable.
Just a side note. I like the idea with a standalone package. However, I suggest to use a soft dependency ("Recommends:") instead of a hard dependency ("Requires:") because the dependent packages will not stop working completely without it and some "enterprise" users might want to install gdb|strace|elfutils without it.
(In reply to Paul Moore from comment #76) > (In reply to Mark Wielaard from comment #75) > > (In reply to Paul Moore from comment #74) > > > #1 - I think the package name "default-yama-scope" is misleading. The > > > default Yama ptrace_scope setting is 1 (restricted-ptrace), not 0. We don't > > > have to use "yama-config-disable", but I strongly believe we should use a > > > package name that makes it very clear that the Yama protections are being > > > disabled. > > > > The idea is that it provides the default attach security permissions (the > > default that the system would normally have, as opposed to the extra > > restricted or admin-only settings). And the user can use the config file to set > > the default they want (being a config file the default isn't overridden once > > the user changes it). > > You didn't name the package "default-linux-scope", you named it > "default-yama-scope". As discussed the value in the inside the sysctl file > is not the default yama setting and there is little in the package name to > indicate ptrace is involved. You are reading way too much into a short name. It is just a short neutral name for what it provides. We could call it "default-yama-scope-config-file-setting-for-traditional-restrictions-overridable-by-the-user" and still get people bikeshed that it isn't "accurate". Even the summary of the discussion in this bug was 50+lines. You won't get that accurately summarized in a short name. See also how your alternative suggestion immediately got people to say how it doesn't accurately describe things (does it enable or disable things?). > I've created a new package, "yama-config-disable-ptrace" (I'll attach it as > soon as I hit reply here), which I think makes it very clear what the > package is doing just from the name. Sigh. I don't think it is more clear, just different. Obviously I like the shorter name without a value judgement about enable/disabling. But that is just bikeshedding. The package is ready and I have other bug fixes already in it that should go into f22 anyway, so we can just resolve this bug now. It seems a little silly to go through all the work and processes to get a new package approved just because you don't like the name. But I cannot stop you trying if you really want. So if you do please: - Pick a more neutral name and make sure the description doesn't say "unrestricted access to ptrace", none of the settings will make ptrace unrestricted, yama doesn't take away restrictions, only tweaks them. See the package description in the existing package that is IMHO more neutral. - Add the same provides as the existing package so either can be used by packages needing the requires. - If you use the %apply_sysctl macro you need a BuildRequires: systemd >= 215 which provides that macro. - Make sure to mention in the config file that changing the default will break installed programs (the config file is only installed if a package requested it and needs that default setting to function properly).
(In reply to Frank Ch. Eigler from comment #78) > Paul, it turns out we don't need unanimity on the name of the RPM; the > client RPMs can decide separately on what option suits them. Heck, they > could include their own sysctl.d files. Yeah, I probably just go forward with the existing solution now for my packages using Requires: default-yama-scope and then if later there is consensus on the ideal RPM name and that package hits f22 and later I can update them to use those.
(In reply to Mark Wielaard from comment #82) > You are reading way too much into a short name. It is just a short neutral > name for what it provides. We could call it > "default-yama-scope-config-file-setting-for-traditional-restrictions- > overridable-by-the-user" and still get people bikeshed that it isn't > "accurate". Even the summary of the discussion in this bug was 50+lines. You > won't get that accurately summarized in a short name. See also how your > alternative suggestion immediately got people to say how it doesn't > accurately describe things (does it enable or disable things?). I stand by my choice of names. If you feel I am reading too much into the name, why would it matter to you what it is called? Pick a new name, but include "yama" and "ptrace" somewhere in the name. > > I've created a new package, "yama-config-disable-ptrace" (I'll attach it as > > soon as I hit reply here), which I think makes it very clear what the > > package is doing just from the name. > > Sigh. I don't think it is more clear, just different. Obviously I like the > shorter name without a value judgement about enable/disabling. But that is > just bikeshedding. The package is ready and I have other bug fixes already > in it that should go into f22 anyway, so we can just resolve this bug now. > It seems a little silly to go through all the work and processes to get a > new package approved just because you don't like the name. No. Just no. The name of the package and the separate package issues are independent. I am against building the yama-ptrace-whatever package as part of elfutils, or any other package for that matter. I feel very strongly that this yama-ptrace-whatever package should exist independent from any other package. I've compromised quite a bit in this BZ, but I'm not willing to compromise on this.
FWIW, I have updated GDB rawhide and F23 to add a "Recommends: default-yama-scope". I can easily change this when/if the new package is ready.
(In reply to Sergio Durigan Junior from comment #85) > FWIW, I have updated GDB rawhide and F23 to add a "Recommends: > default-yama-scope". I can easily change this when/if the new package is > ready. I strongly suggest waiting for the new package.
(In reply to Paul Moore from comment #86) > (In reply to Sergio Durigan Junior from comment #85) > > FWIW, I have updated GDB rawhide and F23 to add a "Recommends: > > default-yama-scope". I can easily change this when/if the new package is > > ready. > > I strongly suggest waiting for the new package. I wanted to, and I also think a new package is the way to go here, but there are so many controversies about the package name and what it should do that I don't know when this new package will be ready. I have already had to manually tweak the yama ptrace scope on 4 machines because of this bug ('attach' stopped working on GDB and several tests started failing). Until the new package is ready, I decided to use Mark's solution because it is already working. As I said, once the new package is ready I can easily switch the Recommends to use it.
(In reply to Paul Moore from comment #86) > I strongly suggest waiting for the new package. Today in my F22 arrived "elfutils-default-yama-scope-0.163-3.fc22.noarch" with "/usr/lib/sysctl.d/10-default-yama-scope.conf" but at boot that results in: Aug 17 05:13:31 monica audit: <audit-1400> avc: denied { sys_ptrace } for pid =817 comm="systemd-sysctl" capability=19 scontext=system_u:system_r:systemd_sys ctl_t:s0 tcontext=system_u:system_r:systemd_sysctl_t:s0 tclass=capability permis sive=0 Aug 17 05:13:31 monica audit: <audit-1300> arch=c000003e syscall=1 success=no ex it=-1 a0=4 a1=7f50e83bf000 a2=2 a3=22 items=0 ppid=1 pid=817 auid=4294967295 uid =0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 c omm="systemd-sysctl" exe="/usr/lib/systemd/systemd-sysctl" subj=system_u:system_ r:systemd_sysctl_t:s0 key=(null) Aug 17 05:13:31 monica audit: <audit-1327> proctitle="/usr/lib/systemd/systemd-s ysctl" Aug 17 05:13:31 monica systemd-sysctl: Failed to write '0' to '/proc/sys/kernel/ yama/ptrace_scope': Operation not permitted Aug 17 05:13:31 monica kernel: audit: type=1400 audit(1439806411.062:75): avc: denied { sys_ptrace } for pid=817 comm="systemd-sysctl" capability=19 scontex t=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:system_r:systemd_sysct l_t:s0 tclass=capability permissive=0 Aug 17 05:13:31 monica kernel: audit: type=1300 audit(1439806411.062:75): arch=c 000003e syscall=1 success=no exit=-1 a0=4 a1=7f50e83bf000 a2=2 a3=22 items=0 ppi d=1 pid=817 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgi d=0 tty=(none) ses=4294967295 comm="systemd-sysctl" exe="/usr/lib/systemd/system d-sysctl" subj=system_u:system_r:systemd_sysctl_t:s0 key=(null) Aug 17 05:13:31 monica kernel: audit: type=1327 audit(1439806411.062:75): procti tle="/usr/lib/systemd/systemd-sysctl" Aug 17 05:13:31 monica systemd: systemd-sysctl.service: main process exited, cod e=exited, status=1/FAILURE Aug 17 05:13:31 monica systemd: Failed to start Apply Kernel Variables. Aug 17 05:13:31 monica systemd: Unit systemd-sysctl.service entered failed state . So, the thing seems to be more complex.
selinux policies need to be updated to permit setting of that sysctl by systemd. Mark, is there a bug# for that already?
bug #1253926
My humble opinion is that this is a half-baked change and we should simply revert the kernel configuration in Fedora 22/23 and approach it better in rawhide.
(In reply to Simo Sorce from comment #91) > My humble opinion is that this is a half-baked change and we should simply > revert the kernel configuration in Fedora 22/23 and approach it better in > rawhide. Strong +1 to this... a kernel change in a F22 update shouldn't suddenly require people to change system configuration in order to keep on doing things that were working before. I'm also not convinced that a good solution has been found here for how to go about enabling ptrace when needed - a guiding Fedora principle has been that simply installing packages does not change configuration. An enterprise user would not expect installing strace via dnf to decrease the security of their system configuration, even if that happened because of a Recommends: rather than a hard requirement. Overall, the decision of whether to allow ptrace of unrelated processes by default is something that needs to be made at the OS level (it's possible that it might have different answers for different editions of Fedora). Packages need to work well, or at least produce coherent error messages with that default.
(In reply to Owen Taylor from comment #92) > (In reply to Simo Sorce from comment #91) > > My humble opinion is that this is a half-baked change and we should simply > > revert the kernel configuration in Fedora 22/23 and approach it better in > > rawhide. > > Strong +1 to this... a kernel change in a F22 update shouldn't suddenly > require people to change system configuration in order to keep on doing > things that were working before. > > I'm also not convinced that a good solution has been found here for how to > go about enabling ptrace when needed BTW. I certainly agree. My personal preference would have been the fix this in the kernel package, either by the original suggestion https://lists.fedoraproject.org/pipermail/kernel/2015-June/005894.html or the one in attachment #3 [details]. But since those two, and other changes like making systemd responsible for fixing the policy as suggested in bug #1234951, were not acceptable to some we ended up with the current compromise solution that nobody really likes, but at least nobody blocks either.
Well if I had veto powers I would certainly block it. It is really *wrong* to change a security configuration just by dragging in apackage via a dependency. It is, in fact, the worst possible way to do it. Would you think acceptable to disable SELinux via a dependcy that just changes the the system configuration ? Probably not, same here.
And bug #1253926 aside, the current implementation has other problem: Right now there is only one package that provides: "default-yama-scope", and the capability is _required_ by elfutils-libs. So an attempt to revert to the kernel default, when ptrace isn't needed, with a naive "dnf remove" results in: # dnf remove elfutils-default-yama-scope Dependencies resolved. Error: The operation would result in removing the following protected packages: systemd, dnf. I think this "default" should not be "required".
(In reply to Simo Sorce from comment #94) > It is really *wrong* to change a security configuration just by dragging in > apackage via a dependency. > > It is, in fact, the worst possible way to do it. Again, agreed. But all the better ways to fix the configuration that were proposed (and implemented and tested) were shot down. Please do try to convince others the earlier fixes are better and should be implemented (there are patches already in this bug). > Would you think acceptable to disable SELinux via a dependcy that just > changes the the system configuration ? Probably not, same here. Right. It should really be done in the kernel imho since that currently sets the policy that breaks user space. Although the analogy doesn't really match. yama isn't selinux. selinux allows you to opt-in and run services in restricted context. You wouldn't enable selinux and install policy by default without first making sure services run correctly under it.
(In reply to Salvador Ortiz from comment #95) > And bug #1253926 aside, the current implementation has other problem: Right > now there is only one package that provides: "default-yama-scope", and the > capability is _required_ by elfutils-libs. > > So an attempt to revert to the kernel default, when ptrace isn't needed, > with a naive "dnf remove" results in: > > # dnf remove elfutils-default-yama-scope > Dependencies resolved. > Error: The operation would result in removing the following protected > packages: systemd, dnf. > > I think this "default" should not be "required". It would be nicer to use recommends, but that isn't available in f22 and the compose tools in f23 don't yet pull in recommends. The fix is because the kernel "default" is wrong, see comment #57. yama shouldn't have been enabled in the kernel or it should have set it to zero to not break user space. A patch for that is in comment #62 and https://lists.fedoraproject.org/pipermail/kernel/2015-August/005962.html With either of those solutions the sysctl file wouldn't have been necessary. But that solution wasn't adopted. So you are right. With this solution you essentially will require an extra sysconf file and the way to change the system default policy now is the edit that sysconf file.
The only person that seemed somewhat against changing the kernel default seems to be Paul. Paul why is that ? I couldn't get it skimming through this bug, and that is clearly the best solution. Care to exaplain ?
Paul tried a patch upstream to make the default configurable, and that was rejected. Our kernel maintainers don't want to carry a patch which changes the default in the source. So we're left with either turning off yama entirely, or shipping a sysctl file in some package.
Then turn it off.
Simo, that would need the fedora kernel folks to revert bug #1196825 = fedora-git commit #ebce054077.
(In reply to Simo Sorce from comment #100) > Then turn it off. That is attachment #4 [details] as proposed in comment #25 with corresponding thread on the kernel list at https://lists.fedoraproject.org/pipermail/kernel/2015-July/thread.html#5931 which was rejected because it turns the config off and then you couldn't change the default value anymore...
I also object to turning it off by default (which is all that has been discussed. 4 different way to just turn of a security feature by default). YAMA has benefit to most users. Tools which need the functionality should tell their users how to decrease system security. Heck there are already at least ptrace and gdb patches for this. Turning on security features comes with pain for some people. I agree. But this is not hard to fix for the few of us who need to use -p in our tracing. Making security opt in is a horrible stupid idea, because the people who likely need to enable it are the ones least likely with the knowledge to do so. In this case it seems obvious that making it opt out is hitting exactly the set of people who know how to create a file in /etc/systemctl.d/ If there is a need to broadly allow this type of thing (I have yet to hear it) then effort should be made to solve that problem. Don't make systems more insecure for everyone. My two cents. But I've yet to understand where the pain of having devs create a sysctl file means we should roll it back for everyone. I feel like I must be missing something...
(In reply to Eric Paris from comment #103) > I also object to turning it off by default (which is all that has been > discussed. 4 different way to just turn of a security feature by default). Only one of the suggestions is about turning the yama config off. All other three explicitly leave it enabled, but change the restricted ptrace_scope setting so no user space breakage happens and the user is in control to set extra restrictions/breakage as they wish. But some people now do object to the introduction of a new sysctl file, so they are now indeed arguing to change to the option to just turn it off because that has effectively the same result. See the summary in comment #55 that explains this does indeed break various ordinary programs, gui programs, reduces the security of some daemons since they are unable to lower privileges, etc. That there are no patches to fix that for most cases pointed out and the few patches that are proposed aren't even submitted to the package maintainers or upstream. There is no genuine attack vector that's actually used in practice. It is even questionable whether this is effective hardening, or just simply user space breakage for no good reason. Since the only cases where the various syscalls and proc interfaces relying on ptrace_scope would work are precisely those context where all information is already available without having to go through ptrace because the program would already be able to read any user files, send signals, open sockets, query for information with the current user credemtials or even simply change the execution environment to insert a prctl(PTRACE_ANY) anyway. So all it really did before the fix was to just break user space.
Where is this question about does this provide additional security? There is no question if it helps. How do you get my active ssh key? Active TLS key? Passwords I store in a password manager like Revelation? Anything that lives in RAM? You can legitimately question if the difficulty/ability to add a sysctl file for your use case vs the security provided is worth it. But saying it is theatre is obviously FUD. I do admit that reptyr is the only example of something that broke which concerns me greatly. It's mitigated in my mind a bit by the fact that, if you are capable of using screen you are capable of editing a text file or installing a package... All of the other examples fit clearly in the later case. Anyone using them can handle this and make their own decisions about their own system. An abrt is a red herring, it already ran as root... elfutils-default-yama-scope.noarch could not be a worse solution. You just disabled a security feature and I can't remove the package you added to my machine in the MIDDLE of F22. I believe this needs to be fix/reverted immediately, or we need a Fesco ticket... (i'm all for an RPM which lets you disable YAMA, heck you can even put it in the default install, but it better not get installed and change my running system and it better not be REQUIRED)
(In reply to Eric Paris from comment #105) > There is no question if it helps. How do you get my active ssh key? Active TLS > key? Passwords I store in a password manager like Revelation? Anything that > lives in RAM? How many of those programs don't already use prctl or other means to protect their secrets? > (i'm all for an RPM which lets you disable YAMA, heck you can even put it in > the default install, but it better not get installed and change my running > system and it better not be REQUIRED) You can edit the new /etc/sysctl.d %config file to set whatever default you judge appropriate for your system.
(In reply to Frank Ch. Eigler from comment #106) > How many of those programs don't already use prctl or other means to protect > their secrets? I hope they all do, but it should be the OS which provides sane security default, not every single application. > > > (i'm all for an RPM which lets you disable YAMA, heck you can even put it in > > the default install, but it better not get installed and change my running > > system and it better not be REQUIRED) > > You can edit the new /etc/sysctl.d %config file to set whatever default you > judge appropriate for your system. Yes I can create a new file in etc to enable (exactly the same as I could before to disable). But you can't seriously believe it would be acceptable for an rpm, especially one as core as elfutils, to just disable selinux on everyone's system, without their consent, in the middle of a release, and tell them they can turn it back on by creating and editing a file?
(In reply to Eric Paris from comment #107) > (In reply to Frank Ch. Eigler from comment #106) > > How many of those programs don't already use prctl or other means to protect > > their secrets? > > I hope they all do, but it should be the OS which provides sane security > default, not every single application. Without prctl, these programs can probably be forced to coredump and expose their secrets. The ptrace part of the protection is slight. > [...] But you can't seriously believe it would be acceptable > for an rpm, especially one as core as elfutils, to just disable selinux on > everyone's system, without their consent, in the middle of a release [...] It merely restores the status quo ante (before bug #1196825). That regression to userspace was done "without their consent ...", and without announcement. Anyway, that's water under the bridge.
(In reply to Frank Ch. Eigler from comment #108) > (In reply to Eric Paris from comment #107) > > [...] But you can't seriously believe it would be acceptable > > for an rpm, especially one as core as elfutils, to just disable selinux on > > everyone's system, without their consent, in the middle of a release [...] > > It merely restores the status quo ante (before bug #1196825). That > regression to userspace was done "without their consent ...", and > without announcement. Anyway, that's water under the bridge. That was done in RAWHIDE with months of opportunity for comment with release notes. This was done in the middle of a stable release. Big big difference. Much the same way SELinux was introduced in FC3. Not in the middle of FC2...
> That was done in RAWHIDE with months of opportunity for comment with release > notes. This change was not noted in the F22 release notes nor on fedora-devel. It was put instead in the "Common F22 Bugs" list.
I've been ignoring this bug, but you guys keep bickering back and forth and it keeps popping up in my inbox. Since the kernel team has no explicit stake on this option, here is what I'm going to propose: F22 and F23 get yama disabled in the kernel config. That renders it impossible to use yama, but allows people that can't be bothered to create a text file or echo into a sysfs entry to use their tools to do whatever it is they are currently prevented from doing. Yama stays enabled in rawhide kernels. You guys actually work towards a solution that is acceptable BEFORE rhel8 even comes into the picture. That way you don't have to have this same argument again later down the road. Does anyone have major objections to this?
no objections
My only concern is that if we turn off Yama, we're never going to turn it back on because I don't see us ever reaching a solution. However, at this point if you want to drop Yama, drop it; I don't think my sanity can take having to explain, yet again, why process separation is an important security property.
What is being proposed is dropping it from Fedora 22 and 23, but leaving it enabled in rawhide. This gives everyone time to come up with a plan for Fedora 24. That should be plenty of time to come up with whatever userspace changes people are comfortable with.
(In reply to Josh Boyer from comment #111) > Does anyone have major objections to this? No objections at all. I just wish you had said this a couple of weeks ago, it would have given us a resolution much earlier :) You don't have to disable the config in f22 and f23, the the current solution we have now does work (even if there is some bickering about the naming of stuff).
(In reply to Mark Wielaard from comment #115) > (In reply to Josh Boyer from comment #111) > > Does anyone have major objections to this? > > No objections at all. I just wish you had said this a couple of weeks ago, > it would have given us a resolution much earlier :) No it wouldn't. There is no resolution here. > You don't have to disable the config in f22 and f23, the the current > solution we have now does work (even if there is some bickering about the > naming of stuff). Seriously? Then why the hell is the bug still open? Is this hacky "solution" going to be used in rhel8?
(In reply to Josh Boyer from comment #116) > (In reply to Mark Wielaard from comment #115) > > (In reply to Josh Boyer from comment #111) > > > Does anyone have major objections to this? > > > > No objections at all. I just wish you had said this a couple of weeks ago, > > it would have given us a resolution much earlier :) > > No it wouldn't. There is no resolution here. Programs are no longer broken, that is what I call a resolution. The same could have been achieved by you proposing to disable the config earlier. That is what I meant. > > You don't have to disable the config in f22 and f23, the the current > > solution we have now does work (even if there is some bickering about the > > naming of stuff). > > Seriously? Then why the hell is the bug still open? I thought the bug was closed now. At least the status is ON_QA. But you are right, I was wrong, the current fix isn't in f22, since at least till recently the f22 kernel didn't have this config enable. So please do disable the config. I was just trying to save you some time, not realizing the config had crept into earlier releases already. > Is this hacky "solution" going to be used in rhel8? I don't know. I hope not. I hope it will be solved directly in the kernel either by disabling the config, having a patch (upstream first I guess) to enable it with ptrace_scope set to zero, or by the kernel shipping the sysconfig file with that setting itself. All those solutions seem nicer than what we are doing now.
(In reply to Mark Wielaard from comment #117) > (In reply to Josh Boyer from comment #116) > > (In reply to Mark Wielaard from comment #115) > > > (In reply to Josh Boyer from comment #111) > > > > Does anyone have major objections to this? > > > > > > No objections at all. I just wish you had said this a couple of weeks ago, > > > it would have given us a resolution much earlier :) > > > > No it wouldn't. There is no resolution here. > > Programs are no longer broken, that is what I call a resolution. The same > could have been achieved by you proposing to disable the config earlier. > That is what I meant. No, that isn't resolution. You and the security people still have a fundamental disagreement here. Your solution is "turn it off." Theirs is "leave it on." It needs to be solved before you guys get anywhere near RHEL8. > > > You don't have to disable the config in f22 and f23, the the current > > > solution we have now does work (even if there is some bickering about the > > > naming of stuff). > > > > Seriously? Then why the hell is the bug still open? > > I thought the bug was closed now. At least the status is ON_QA. > But you are right, I was wrong, the current fix isn't in f22, since at least > till recently the f22 kernel didn't have this config enable. So please do > disable the config. I was just trying to save you some time, not realizing > the config had crept into earlier releases already. It didn't creep in. F22 was released with YAMA enabled. It is maddening that people have to keep repeating themselves on multiple points on this bug. > > Is this hacky "solution" going to be used in rhel8? > > I don't know. I hope not. I hope it will be solved directly in the kernel > either by disabling the config, having a patch (upstream first I guess) to > enable it with ptrace_scope set to zero, or by the kernel shipping the > sysconfig file with that setting itself. All those solutions seem nicer than > what we are doing now. You might want to clone this bug against RHEL so you can hash it out there. This bug is going away one way or another within a weeks time.
(In reply to Mark Wielaard from comment #117) > ... having a patch (upstream first I guess) to enable it with ptrace_scope set > to zero ... FYI, this is not a possibility, upstream has rejected this idea.
(In reply to Josh Boyer from comment #116) > Is this hacky "solution" going to be used in rhel8? I hope for our sakes, and those of our customers, that the hack isn't in RHEL8. I would like to think that our commitment to security in RHEL would preempt Mark's objections, but I'm done fighting for this, I need to work on other things.
Here, different desiderata conflict (apparent security vs. user-space behavior continuity). There is apparently no pure win-win solution. If we were to pursue a change such as this, we would need to communicate the tradeoffs, and ideally offer users a suite of easy (systemwide?) knobs (RPMs?) to express a general security-vs-otherstuff preference.
(In reply to Paul Moore from comment #120) > I hope for our sakes, and those of our customers, that the hack isn't in > RHEL8. > > I would like to think that our commitment to security in RHEL would preempt > Mark's objections, but I'm done fighting for this, I need to work on other > things. We also care a great deal about tools in RHEL, so it's not as simple as just flipping on every possible security feature.
(In reply to Josh Boyer from comment #118) > (In reply to Mark Wielaard from comment #117) > > Programs are no longer broken, that is what I call a resolution. The same > > could have been achieved by you proposing to disable the config earlier. > > That is what I meant. > > No, that isn't resolution. You and the security people still have a > fundamental disagreement here. Your solution is "turn it off." Theirs is > "leave it on." I honestly thought we finally settled and fixed this bug a couple of weeks ago. After a long debate indeed. yama is very black or white. The config is either on or off and the default setting is either 0 or 1 (theoretically there is also 2 and 3, but nobody has argued that is a good idea). So it might look like a binary thing, because the answer has to be either 0 or 1. But that doesn't mean the discussion and tradeoffs were binary. The fix chosen wasn't even mine. I just implemented it to finally get the bug resolved. Personally I would have liked to see a different solution. It was most certainly a compromise. The real solution is probably making yama more flexible. > > > > You don't have to disable the config in f22 and f23, the the current > > > > solution we have now does work (even if there is some bickering about the > > > > naming of stuff). > > > > Seriously? Then why the hell is the bug still open? > > I thought the bug was closed now. At least the status is ON_QA. > > But you are right, I was wrong, the current fix isn't in f22, since at least > > till recently the f22 kernel didn't have this config enable. So please do > > disable the config. I was just trying to save you some time, not realizing > > the config had crept into earlier releases already. > > It didn't creep in. F22 was released with YAMA enabled. It is maddening > that people have to keep repeating themselves on multiple points on this bug. I mixed up my versions. My apologies. I was correct the first time. But got confused when you said the bug was still open. Just trying to safe you some time by pointing out the correct version. Then badly failing by mixing up the actual numbers. Sorry.
(In reply to Josh Boyer from comment #111) > I've been ignoring this bug, but you guys keep bickering back and forth and > it keeps popping up in my inbox. Since the kernel team has no explicit > stake on this option, here is what I'm going to propose: > > F22 and F23 get yama disabled in the kernel config. That renders it > impossible to use yama, but allows people that can't be bothered to create a > text file or echo into a sysfs entry to use their tools to do whatever it is > they are currently prevented from doing. > > Yama stays enabled in rawhide kernels. You guys actually work towards a > solution that is acceptable BEFORE rhel8 even comes into the picture. That > way you don't have to have this same argument again later down the road. > > > Does anyone have major objections to this? I do. AFAICS, Yama ptrace restrictions are already being default-disabled in F22 and F23 via /usr/lib/sysctl.d/10-default-yama-scope.conf, so there should be no breakage for ptrace in the default configuration of any up-to-date F22/F23 system, yet users can explicitly opt into Yama ptrace restrictions by creating an /etc/sysctl.d/10-default-yama-scope.conf file with their own desired setting. Why disable it in the kernel and prevent users from even opting into it? For F24, if we could switch from requires to recommends and ideally move it to a separate package, then that would be an improvement. Are there any real objections or obstacles to that? What needs to be done to make that happen? If that did happen, then would it be possible to have a minimal server or desktop install that did not install /usr/lib/sysctl.d/10-default-yama-scope.conf and thus did not default-disable Yama ptrace restrictions? That would be good. On a different but related note, I am a little concerned about the abrt discussion earlier in this bug. I never saw the actual bug regarding abrt, so I don't have much context, but changing abrt-hook-ccpp to run as root to work around Yama ptrace restrictions doesn't sound like a security improvement to me. That really ought to get looked at more closely IMHO.
(In reply to Mark Wielaard from comment #123) > (In reply to Josh Boyer from comment #118) > > (In reply to Mark Wielaard from comment #117) > > > Programs are no longer broken, that is what I call a resolution. The same > > > could have been achieved by you proposing to disable the config earlier. > > > That is what I meant. > > > > No, that isn't resolution. You and the security people still have a > > fundamental disagreement here. Your solution is "turn it off." Theirs is > > "leave it on." > > I honestly thought we finally settled and fixed this bug a couple of weeks > ago. After a long debate indeed. yama is very black or white. The config is > either on or off and the default setting is either 0 or 1 (theoretically > there is also 2 and 3, but nobody has argued that is a good idea). So it > might look like a binary thing, because the answer has to be either 0 or 1. > But that doesn't mean the discussion and tradeoffs were binary. The fix > chosen wasn't even mine. I just implemented it to finally get the bug > resolved. Personally I would have liked to see a different solution. It was > most certainly a compromise. The real solution is probably making yama more > flexible. No, see what you did is implement it in a way that makes it the default over Paul's objections. Making it a subpackage of elfutils was not a compromise. Paul was already doing the work to provide a separate package for this. Here, let me quote his objections so they're clear: (In reply to Paul Moore from comment #84) > No. Just no. > > The name of the package and the separate package issues are independent. I > am against building the yama-ptrace-whatever package as part of elfutils, or > any other package for that matter. I feel very strongly that this > yama-ptrace-whatever package should exist independent from any other package. > > I've compromised quite a bit in this BZ, but I'm not willing to compromise > on this. His package review is here: https://bugzilla.redhat.com/show_bug.cgi?id=1250179 So now what you've done is make elfutils-libs require default-yama-scope, which is provided by elfutils itself. So anything that requires elfutils-libs gets the security setting turned off. So what requires libdw.so? Things like: [jwboyer@vader linux]$ rpm -q --whatrequires "libdw.so.1()(64bit)" btparser-0.26-2.fc20.x86_64 kexec-tools-2.0.8-8.fc22.x86_64 satyr-0.19-1.fc22.x86_64 elfutils-libs-0.163-3.fc22.x86_64 systemd-libs-219-21.fc22.x86_64 systemd-219-21.fc22.x86_64 libgudev1-219-21.fc22.x86_64 systemd-python3-219-21.fc22.x86_64 systemd-python-219-21.fc22.x86_64 systemd-compat-libs-219-21.fc22.x86_64 elfutils-0.163-3.fc22.x86_64 elfutils-devel-0.163-3.fc22.x86_64 perf-4.1.6-200.fc22.x86_64 [jwboyer@vader linux]$ rpm -q --whatprovides "libdw.so.1()(64bit)" elfutils-libs-0.163-3.fc22.x86_64 [jwboyer@vader linux]$ rpm -qR elfutils-libs /sbin/ldconfig /sbin/ldconfig default-yama-scope Oh. So systemd is in the list. Which means EVERY FEDORA INSTALL now has YAMA turned off by default. This is not compromise. Compromise would have been waiting for Paul to finish his work and then having the tools actually impacted (like gdb, and strace I guess) have a Requires or Recommends on that separate stand-alone package.
(In reply to Stephen Smalley from comment #124) > (In reply to Josh Boyer from comment #111) > > I've been ignoring this bug, but you guys keep bickering back and forth and > > it keeps popping up in my inbox. Since the kernel team has no explicit > > stake on this option, here is what I'm going to propose: > > > > F22 and F23 get yama disabled in the kernel config. That renders it > > impossible to use yama, but allows people that can't be bothered to create a > > text file or echo into a sysfs entry to use their tools to do whatever it is > > they are currently prevented from doing. > > > > Yama stays enabled in rawhide kernels. You guys actually work towards a > > solution that is acceptable BEFORE rhel8 even comes into the picture. That > > way you don't have to have this same argument again later down the road. > > > > > > Does anyone have major objections to this? > > I do. AFAICS, Yama ptrace restrictions are already being default-disabled > in F22 and F23 via /usr/lib/sysctl.d/10-default-yama-scope.conf, so there > should be no breakage for ptrace in the default configuration of any > up-to-date F22/F23 system, yet users can explicitly opt into Yama ptrace > restrictions by creating an /etc/sysctl.d/10-default-yama-scope.conf file > with their own desired setting. > Why disable it in the kernel and prevent users from even opting into it? This is fine with me. Since in effect it's already been disabled everywhere I see no problems with leaving it on in the kernel. I hadn't realized it was already effectively disabled until I dug further. > For F24, if we could switch from requires to recommends and ideally move it > to a separate package, then that would be an improvement. Are there any > real objections or obstacles to that? What needs to be done to make that > happen? I have no idea, but hopefully that compromise actually happens at some point. > If that did happen, then would it be possible to have a minimal server or > desktop install that did not install > /usr/lib/sysctl.d/10-default-yama-scope.conf and thus did not > default-disable Yama ptrace restrictions? That would be good. > > On a different but related note, I am a little concerned about the abrt > discussion earlier in this bug. I never saw the actual bug regarding abrt, > so I don't have much context, but changing abrt-hook-ccpp to run as root to > work around Yama ptrace restrictions doesn't sound like a security > improvement to me. That really ought to get looked at more closely IMHO. Preferably in a separate bug.
From a kernel perspective, there's nothing to be done here. I'm closing this. Hopefully you guys sit down and work this out before it impacts RHEL. There's no appropriate resolution here, so CANTFIX will have to do.
(In reply to Josh Boyer from comment #125) > [...] > > But that doesn't mean the discussion and tradeoffs were binary. The fix > > chosen wasn't even mine. I just implemented it to finally get the bug > > resolved. Personally I would have liked to see a different solution. It was > > most certainly a compromise. The real solution is probably making yama more > > flexible. > > No, see what you did is implement it in a way that makes it the default over > Paul's objections. > Making it a subpackage of elfutils was not a compromise. > Paul was already doing the work to provide a separate package for this. > Here, let me quote his objections so they're clear: There were complaints about the subpackage name, and its parent src.rpm. Those are in no way material to the question of the default value or dependencies. > So now what you've done is make elfutils-libs require default-yama-scope, That is probably because several elfutils binaries use ptrace(2)-dependent parts of elfutils-libs. > Oh. So systemd is in the list. Which means EVERY FEDORA INSTALL now has > YAMA turned off by default. This is not compromise. Fair enough - but it is restoring the status quo ante, solving the "common bug". > Compromise would have been waiting for Paul to finish his work and then > having the tools actually impacted (like gdb, and strace I guess) have > a Requires or Recommends on that [...] ... and elfutils, see above! One possible compromise, even at this stage, could be to switch the yama subrpm dependency to be based on elfutils (i.e., the /usr/bin/* files) rather than elfutils-libs. It is possible that I'm missing other reasons for the -libs->yama dependency though.
BTW, on the bikeshedding front, it seems to me that neither the package name (elfutils-default-yama-scope or just default-yama-scope if separated) nor the sysctl file name (10-default-yama-scope.conf) lend themselves to user discoverability or understanding, since the names don't even include the word "ptrace" and if the user knew what "yama" was in the first place, he probably wouldn't need a prepackaged sysctl file to disable its restrictions. As noted before, Ubuntu simply names its sysctl file as 10-ptrace.conf, which is both short and to the point and enhances user discoverability (oh, ptrace isn't working, and here's a sysctl file that has something to do with that). I'll agree that yama-config-disable-ptrace isn't great either as a package name (confusing as to whether it is disabling ptrace or restrictions on ptrace as others have noted, and still puts the emphasis on yama even though that is less discoverable/understandable to the user than the fact that it has to do with ptrace), but it at least has the word "ptrace" in it. However, the sysctl file name (10-yama-ptrace-scope.conf) used within that package seems a bit more discoverable and is no more verbose than default-yama-scope. Since just "ptrace" might ambiguous, couldn't it just be "ptrace-scope" and "10-ptrace-scope.conf"? At the end of the day, it is just another kernel feature turned on or off by a sysctl knob; it doesn't matter that it is implemented by something called Yama.
[jss@Il-Duce ~]$ top top - 02:53:31 up 5:36, 5 users, load average: 1.17, 1.16, 1.20 Tasks: 244 total, 2 running, 239 sleeping, 0 stopped, 3 zombie %Cpu(s): 9.5 us, 4.7 sy, 0.5 ni, 85.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 18487852 total, 15579768 free, 1077068 used, 1831016 buff/cache KiB Swap: 0 total, 0 free, 0 used. 17241420 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8551 jss 20 0 968608 103784 46192 R 101.3 0.6 133:26.37 enlightenment Enlightenment, running as a normal user, is chewing CPU, so i go to strace it, and get this: [root@Il-Duce ~]# cat /proc/sys/kernel/yama/ptrace_scope 0 [root@Il-Duce ~]# strace -p 8551 strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted This is on the latest fedora22 kernel: [root@Il-Duce ~]# uname -a Linux Il-Duce 4.2.3-200.fc22.x86_64 #1 SMP Thu Oct 8 03:23:55 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux What a complete and utter abortion.
Sorry, nevermind. Turns out enlightenment was already being traced by enlightenment_start. Supposedly so it can be restarted if it crashes. Craziest way of doing that, that i've ever heard of... So the fix is to: killall -USR1 enlightenment_start When enlightenment_start catches this signal it stops tracing enlightenment and then it can be straced by root user. Christ, what a PITA.