Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Fri, Apr 13, 2012 at 10:26:06AM -0400, Daniel J Walsh wrote: Trying to fix all apps that could include confidential data from Programmer Debugging tools which are a very small percentage of users use, is just crazy. It isn't just debugging tools that would break, also things like wine, the java tools, performance and tracing tools, etc. And even if they were a small percentage of the users, it is an important part of Fedora. It would set an extremely bad precedent if we would make it harder for users to be programmers. We now have a feature for those who care about security that can stop any process on the system from reading/modifying the memory of any other process on the system. If sysadmins want to take advantage of this they can, If they do not then can turn it off. It is good to have the feature. It is just crazy to turn it on by default as long as that means breaking a normal install. We already have solutions for the most important security sensitive programs like gnome-keytools and ssh-agent. We don't have to go for perfect security as long as there is no satisfactory solution to just clobbering normal functionality for all users (and make then unbreak their machines and/or disable selinux for good, which IMHO would be a bad thing). Thanks, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Thu, Apr 12, 2012 at 04:01:58PM -0400, Daniel J Walsh wrote: On 04/12/2012 02:39 PM, Mark Wielaard wrote: On Mon, Apr 09, 2012 at 09:38:40AM -0400, Eric Paris wrote: (Think about it a moment. gdb -p is the same as firefox trying to ptrace gnome-keyring) I thought a bit about it. And now I am even more confused :) It seems you are already not allowed to ptrace gnome-keyring-daemon (or ssh-agent because that is setuid). So is there a better example than gnome-keyring or ssh-agent to show why we would like to clobber ptrace globally? Ok kinit, ssh, pwsafe ... But these are different aren't they? Because they aren't long running daemons holding security/authentication credentials for the user. To exploit these you would not have to ptrace attach to them, but will have to actively start a run of them and trick the user into typing in their passwords. Or do you mean they could ptrace some other process when they are compromised? evince ptracing firefox And this seems yet another different security threat, where you have a desktop app that might execute untrusted data to get exploited. Doesn't it make sense to confine these applications like we confine say httpd so they cannot meddle with other programs directly? Does firefox hold security credentials itself? If so, would it make sense to deal with this threat by moving those to a small secured deamon that is protected the same way ssh-agent/gnome-keyring are? I am just looking for specific security threats and see if they can be handled in a nicer way than clobbering ptrace globally. It seems we already have something for the security deamons running on behave of the user (ssh-agent/gnome-keyring-daemon), so hopefully we can find similar protections for other cases before we start globally stopping anybody from ptracing unless they get elivated privileges first to unbreak their machines. Thanks, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/13/2012 03:55 AM, Mark Wielaard wrote: On Thu, Apr 12, 2012 at 04:01:58PM -0400, Daniel J Walsh wrote: On 04/12/2012 02:39 PM, Mark Wielaard wrote: On Mon, Apr 09, 2012 at 09:38:40AM -0400, Eric Paris wrote: (Think about it a moment. gdb -p is the same as firefox trying to ptrace gnome-keyring) I thought a bit about it. And now I am even more confused :) It seems you are already not allowed to ptrace gnome-keyring-daemon (or ssh-agent because that is setuid). So is there a better example than gnome-keyring or ssh-agent to show why we would like to clobber ptrace globally? Ok kinit, ssh, pwsafe ... But these are different aren't they? Because they aren't long running daemons holding security/authentication credentials for the user. To exploit these you would not have to ptrace attach to them, but will have to actively start a run of them and trick the user into typing in their passwords. Or do you mean they could ptrace some other process when they are compromised? evince ptracing firefox And this seems yet another different security threat, where you have a desktop app that might execute untrusted data to get exploited. Doesn't it make sense to confine these applications like we confine say httpd so they cannot meddle with other programs directly? Does firefox hold security credentials itself? If so, would it make sense to deal with this threat by moving those to a small secured deamon that is protected the same way ssh-agent/gnome-keyring are? I am just looking for specific security threats and see if they can be handled in a nicer way than clobbering ptrace globally. It seems we already have something for the security deamons running on behave of the user (ssh-agent/gnome-keyring-daemon), so hopefully we can find similar protections for other cases before we start globally stopping anybody from ptracing unless they get elivated privileges first to unbreak their machines. Thanks, Mark I am not going to argue about perfect security. I am just trying to raise the bar. First off it is almost impossible to confine desktop apps in any meaningful way that will not break user experience. If I turned on any of the protections we have for these the outcry would make the deny_ptrace ideas seem mild. Trying to fix all apps that could include confidential data from Programmer Debugging tools which are a very small percentage of users use, is just crazy. We now have a feature for those who care about security that can stop any process on the system from reading/modifying the memory of any other process on the system. If sysadmins want to take advantage of this they can, If they do not then can turn it off. Just like they can turn off SELinux/firewalls/passwd security or just run their desktop as root... Machines with developers on them can keep the feature disabled. This dead horse has been beaten to death. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Wed, 2012-04-11 at 10:51 -0400, Daniel J Walsh wrote: On 04/11/2012 10:21 AM, Matthew Garrett wrote: I'm in favour of keeping ptrace available for F17 - I don't think we've had enough opportunity to discuss the tradeoffs. deny_ptrace will be DISABLED for F17. Already checked in. Thanks, and again apologies we are having this discussion so late into the release. But at least everybody should now be well aware this will come back for F18. I think we can have levels of denial. Once we can separate out gdb foobar from gdb -p 1234, we can have multiple booleans, to deny different accesses, and allow the administrator to choose which level can be blocked. Do you have an overview how to handle all these layers/booleans? At times it seems this is only about gdb, but this does break a lot more stuff out of the box when enabled. Of course there is strace and ltrace. But also things that use gdb underneath like pstack, gcore, or IDEs like eclipse or nemiver. Crash interceptors, like KDE's DrKonqui, but I believe firefox and chrome also come with their own (abrt for now works around it by dumping a core file to disk and then examining that, but that seems a little wasteful IMHO). java tools like jinfo/jmap/jstack use ptrace to provide users information about system properties, memory usage, java backtraces, etc. of running java processes, wine uses ptrace for some of its inter-process communication. If you could create an overview how all these things are handled (hopefully by making them just work out of the box, and not requiring people to unbreak their box or having to use root privileges) with the feature enabled by default that would be really appreciated. Some of these programs don't provide much help or just plain crash if ptrace is globally disabled. So there should at least be an effort to clean them all up and make them aware of the different ways ptrace may fail (somewhat complicated by the fact that it seems there is just one generic EPERM error given, whether it really is not your process or something like SELinuxDenyPtrace). Thanks, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
dwalsh wrote: [...] deny_ptrace will be DISABLED for F17. Already checked in. [...] Note that the selinux-policy rpm update that corrects this has not yet been pushed to any yum update/-testing channels. It would be a shame if the f17 beta spin went out with this bug. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-113.fc17 - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Thu, Apr 12, 2012 at 4:53 PM, Frank Ch. Eigler f...@redhat.com wrote: dwalsh wrote: [...] deny_ptrace will be DISABLED for F17. Already checked in. [...] Note that the selinux-policy rpm update that corrects this has not yet been pushed to any yum update/-testing channels. It would be a shame if the f17 beta spin went out with this bug. Beta is already closed afaik. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Niels de Vos said: On Mon, Apr 9, 2012 at 3:38 PM, Eric Paris eparis at redhat.com wrote: On Mon, 2012-04-09 at 00:31 +0200, Kevin Kofler wrote: It also breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by disabling the flag in kde-runtime's %post script, but there are other similar debuggers in upstream software, some not packaged in Fedora) I ask in the bug how DrKonqi works on other distros with the YAMA security module enabled which implements a slightly different semantic and didn't hear a response. I have patches which I will try to get into the Fedora kernel later today that will allow us to seamlessly allow gdb to trace children. gdb -p would still require disabling the boolean. (Think about it a moment. gdb -p is the same as firefox trying to ptrace gnome-keyring) Eric and Dan, please don't reinvent the wheel here. It seems that there is prctl() call to allow a specific PID (like gdb stared by the signal-handler of DrKonqi) to trace the calling/crached process. The idea comes from following the gdb discussion here: - http://sourceware.org/ml/gdb-patches/2012-03/msg00274.html Please just use Yama -- it's already in the mainline kernel[1]. You don't need to create anything new. All the crash handlers and other tools (Firefox, Chrome, DrKonqi/KDE, and Wine) are already aware of how to declare ptrace relationships with prctl(PR_SET_PTRACER) from when I wrote Yama and sent patches to various upstreams. Just allowing child process relationships isn't sufficient, which is why PR_SET_PTRACER was created so that things like Wine could declare the entire cluster of wine-server-spawned processes as ptraceable, etc. Why go a totally new route when all of these problems were already solved? Please just read through the module documentation[2] and enable it[3], it'll make all of this just go away. You can even patch the ptrace manpage for PTRACE_ATTACH[4] so people know where to get more details. -Kees [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=security/yama;hb=HEAD [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/security/Yama.txt;hb=HEAD [3] http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=commitdiff;h=25de2d649334d53ab168eb8178e0889a3533f3c1 [4] http://manpages.ubuntu.com/ptrace -- Kees Cook -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Thu, 2012-04-12 at 08:05 -0700, Kees Cook wrote: Please just use Yama -- it's already in the mainline kernel[1]. You don't need to create anything new. All the crash handlers and other tools (Firefox, Chrome, DrKonqi/KDE, and Wine) are already aware of how to declare ptrace relationships with prctl(PR_SET_PTRACER) from when I wrote Yama and sent patches to various upstreams. Just allowing child process relationships isn't sufficient, which is why PR_SET_PTRACER was created so that things like Wine could declare the entire cluster of wine-server-spawned processes as ptraceable, etc. Why go a totally new route when all of these problems were already solved? To be honest, and like we discussed on irc yesterday, it seems Yama has all the same problems like the current solution. It denies ptrace attach to your own processes by default which is what breaks lots of things (we were discussing just jinfo/jstack/jmap yesterday, and I found that issue without even trying). None of the solutions that you claim Yama provides unbreaks these tools. IMHO just adding documentation and hoping users finds that and are allowed to unbreak their own setup isn't a real solution. It is fine to confine some applications so they cannot ptrace attach to arbitrary processes, but just globally disabling ptrace attach even for unconfined users is just rude IMHO, not to mention highly unsocial (as if our users wouldn't be hackers interested how stuff works). Cheers, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Hi, On Thu, Apr 12, 2012 at 05:18:59PM +0200, Mark Wielaard wrote: On Thu, 2012-04-12 at 08:05 -0700, Kees Cook wrote: Please just use Yama -- it's already in the mainline kernel[1]. You don't need to create anything new. All the crash handlers and other tools (Firefox, Chrome, DrKonqi/KDE, and Wine) are already aware of how to declare ptrace relationships with prctl(PR_SET_PTRACER) from when I wrote Yama and sent patches to various upstreams. Just allowing child process relationships isn't sufficient, which is why PR_SET_PTRACER was created so that things like Wine could declare the entire cluster of wine-server-spawned processes as ptraceable, etc. Why go a totally new route when all of these problems were already solved? To be honest, and like we discussed on irc yesterday, it seems Yama has all the same problems like the current solution. It denies ptrace attach to your own processes by default which is what breaks lots of things (we were discussing just jinfo/jstack/jmap yesterday, and I found that issue without even trying). None of the solutions that you claim Yama provides unbreaks these tools. IMHO just adding documentation and hoping users finds that and are allowed to unbreak their own setup isn't a real solution. It is fine to confine some applications so they cannot ptrace attach to arbitrary processes, but just globally disabling ptrace attach even for unconfined users is just rude IMHO, not to mention highly unsocial (as if our users wouldn't be hackers interested how stuff works). Right, and that's where we disagree, which is fine. Ubuntu and Chrome OS take the stance than improving the security of the bulk of their users in this way outweighs the one-time inconvenience to some developers. My point isn't whether or not to restrict ptrace, but rather, if you're going to, please start with Yama and go from there. It's upstream, and it already solves a number of problems associated with just globally disabling ptrace, allowing for crash handlers and emulators to still do their job. -Kees -- Kees Cook -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/12/2012 02:39 PM, Mark Wielaard wrote: On Mon, Apr 09, 2012 at 09:38:40AM -0400, Eric Paris wrote: (Think about it a moment. gdb -p is the same as firefox trying to ptrace gnome-keyring) I thought a bit about it. And now I am even more confused :) It seems you are already not allowed to ptrace gnome-keyring-daemon (or ssh-agent because that is setuid). So is there a better example than gnome-keyring or ssh-agent to show why we would like to clobber ptrace globally? Thanks, Mark Ok kinit, ssh, pwsafe ... evince ptracing firefox -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Tue, 2012-04-10 at 14:04 +0100, Matthew Garrett wrote: Option 2: Disable ptrace for everything except direct child processes. Allows the common case of running a task directly under a tool like gdb or strace, but forbids attaching one to an already running task. May break some of the same tools as option 1. Ubuntu defaults to this behaviour. This refers to the proposal to deny PTRACE_ATTACH, but not PTRACE_TRACEME? Is that really that significant in the security analysis? The threat as I understand it is that someone could read the memory of gnome-key-ring and get access to private keys or passwords protecting the private keys. But if an attacker can trace an invocation of say gnome-keyring-daemon --replace isn't that just as bad? Option 4: Identify the set of most vulnerable applications, run them in confined domains and either forbid them access to ptrace or permit them only to ptrace children. This might expand to most/all gui applications (since it would necessarily include any viewers that applications spawn for showing downloaded remote data), but this seems a better option to me. To a first approximation, simply auditing the distribution for anything that opens files or reads information from the network and forbidding them ptrace access (and denying ptrace access from any existing confined domains except, maybe, staff_t) seems like it would get us most of the way to option 4 without breaking existing user expectations. What am I missing that makes this infeasible? As far as I understand, this would work, if anything spawned from firefox would also be in a no-introspection-context. But not in time for F17. So the questions really is whether or not we keep breaking user expectations and make developers unbreak their machines in F17. Cheers, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Mon, Apr 09, 2012 at 12:08:13PM +0200, Matej Cepl wrote: On 8.4.2012 22:50, Tom Lane wrote: And, as I said, the alternative is that this gets turned off, by me and probably a very large fraction of other Fedora users. Without getting into this discussion much, I would just note a bit of shocking news for you ... I am afraid you are not an ordinary Fedora user. If abrt/breakpad/etc. works as they should, then I don't think majority of Fedora users have any reason why to pull out gdb at all. I see Fedora as more of a developer's distro. The mission (particularly Features First) implies that to me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Wed, Apr 11, 2012 at 03:58:55PM +0200, Mark Wielaard wrote: On Tue, 2012-04-10 at 14:04 +0100, Matthew Garrett wrote: Option 2: Disable ptrace for everything except direct child processes. Allows the common case of running a task directly under a tool like gdb or strace, but forbids attaching one to an already running task. May break some of the same tools as option 1. Ubuntu defaults to this behaviour. This refers to the proposal to deny PTRACE_ATTACH, but not PTRACE_TRACEME? Is that really that significant in the security analysis? The threat as I understand it is that someone could read the memory of gnome-key-ring and get access to private keys or passwords protecting the private keys. But if an attacker can trace an invocation of say gnome-keyring-daemon --replace isn't that just as bad? If the user can inject enough code into an unconfined application to invoke another application and trace that, the user can inject enough code into an unconfined application to just pop up something that looks like a keyring prompt and get the user credentials that way. To a first approximation, simply auditing the distribution for anything that opens files or reads information from the network and forbidding them ptrace access (and denying ptrace access from any existing confined domains except, maybe, staff_t) seems like it would get us most of the way to option 4 without breaking existing user expectations. What am I missing that makes this infeasible? As far as I understand, this would work, if anything spawned from firefox would also be in a no-introspection-context. But not in time for F17. So the questions really is whether or not we keep breaking user expectations and make developers unbreak their machines in F17. I'm in favour of keeping ptrace available for F17 - I don't think we've had enough opportunity to discuss the tradeoffs. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/11/2012 10:21 AM, Matthew Garrett wrote: On Wed, Apr 11, 2012 at 03:58:55PM +0200, Mark Wielaard wrote: On Tue, 2012-04-10 at 14:04 +0100, Matthew Garrett wrote: Option 2: Disable ptrace for everything except direct child processes. Allows the common case of running a task directly under a tool like gdb or strace, but forbids attaching one to an already running task. May break some of the same tools as option 1. Ubuntu defaults to this behaviour. This refers to the proposal to deny PTRACE_ATTACH, but not PTRACE_TRACEME? Is that really that significant in the security analysis? The threat as I understand it is that someone could read the memory of gnome-key-ring and get access to private keys or passwords protecting the private keys. But if an attacker can trace an invocation of say gnome-keyring-daemon --replace isn't that just as bad? If the user can inject enough code into an unconfined application to invoke another application and trace that, the user can inject enough code into an unconfined application to just pop up something that looks like a keyring prompt and get the user credentials that way. To a first approximation, simply auditing the distribution for anything that opens files or reads information from the network and forbidding them ptrace access (and denying ptrace access from any existing confined domains except, maybe, staff_t) seems like it would get us most of the way to option 4 without breaking existing user expectations. What am I missing that makes this infeasible? As far as I understand, this would work, if anything spawned from firefox would also be in a no-introspection-context. But not in time for F17. So the questions really is whether or not we keep breaking user expectations and make developers unbreak their machines in F17. I'm in favour of keeping ptrace available for F17 - I don't think we've had enough opportunity to discuss the tradeoffs. deny_ptrace will be DISABLED for F17. Already checked in. I think we can have levels of denial. Once we can separate out gdb foobar from gdb -p 1234, we can have multiple booleans, to deny different accesses, and allow the administrator to choose which level can be blocked. And yes if a process gets enough control to fool the user, then we have lost. But we are basically after incremental improvements in the security. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/11/2012 05:19 PM, Richard W.M. Jones wrote: On Mon, Apr 09, 2012 at 12:08:13PM +0200, Matej Cepl wrote: On 8.4.2012 22:50, Tom Lane wrote: And, as I said, the alternative is that this gets turned off, by me and probably a very large fraction of other Fedora users. Without getting into this discussion much, I would just note a bit of shocking news for you ... I am afraid you are not an ordinary Fedora user. If abrt/breakpad/etc. works as they should, then I don't think majority of Fedora users have any reason why to pull out gdb at all. I see Fedora as more of a developer's distro. The mission (particularly Features First) implies that to me. So do I. I also believe that Linux adoption is in a big part driven by enthusiasts who install it to their friends' computers and invite others to try. Because of this, it is important to cater for such power users and developers, as they are the ones who eventually spread the word that Fedora is a good distribution. This is the reason why I find it important to make the life as good as possible for the power users / developers / enthusiasts: when the they like using Fedora and developing software with Fedora, they're likely to also invite other people to try Fedora out. Which means more users, more developers, more people to spread the word. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Wed, 11 Apr 2012, Kalev Lember wrote: This is the reason why I find it important to make the life as good as possible for the power users / developers / enthusiasts: when the they like using Fedora and developing software with Fedora, they're likely to also invite other people to try Fedora out. Which means more users, more developers, more people to spread the word. While true, it is totally irrelevant to this discussion. I might as well say that SElinux is responsible for Fedora being a distribution without viruses and malware, unlike windows and mac, and so it is exactly the additional security and lack of anti-malware tools bringing your computer to a grinding halt that is the success of fedora you list above. When i was debugging why passwd was segfaulting, I installed gdb and guess what, it denied me ptrace, as it should! However, it even told me within gdb what to type to change the selinux boolean to continue with the gdb session, no different then gdb telling you how and which debuginfo packages to install. Once the automatic debugger helpers are working, I really hope ptrace will be denied again per default, as it would be a very workable good useful security addition to the system. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On Tue, 10 Apr 2012 04:41:46 +0200, Kevin Kofler wrote: Mozilla plugins is usually a euphemism for proprietary crap, most often Flash. We cannot package that in Fedora. So if there is the easy installability of proprietary crap like Mozilla plugins why aren't also the repositories like RPMforge pre-configured automatically? What is the difference between RPMforge and Mozilla plugins database? Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 9.4.2012 22:55, Daniel J Walsh wrote: DrKonqi are, we should disable the ability of any process on their desktop from being able to read/manipulate other processes on their desktop. This is actually IMHO a mistake ... DrKonqi (KDE version of abrt-gui) is exactly for people who have no clue what it is about. That should be allowed as much as abrt (hopefully) is. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On 10.4.2012 08:04, Jan Kratochvil wrote: So if there is the easy installability of proprietary crap like Mozilla plugins why aren't also the repositories like RPMforge pre-configured automatically? What is the difference between RPMforge and Mozilla plugins database? a) there is no difference in their content ... neither of them is controlled by Red Hat or Fedora project, so we cannot be blamed for whatever there is there, b) as for linking ... I would think that MoFo (being a US corporation) is under the same gun as Red Hat is with regards to patents, DMCA and similar lovely stuff. And of course, IANALAM. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Le mardi 10 avril 2012 à 02:57 +0100, Matthew Garrett a écrit : On Mon, Apr 09, 2012 at 09:18:13PM -0400, Daniel J Walsh wrote: On 04/09/2012 05:06 PM, Matthew Garrett wrote: On Mon, Apr 09, 2012 at 04:55:27PM -0400, Daniel J Walsh wrote: And guess what I use these tools, and I just execute setsebool deny_ptrace 0 anytime I need to strace or debug an application, then I turn it back on when I am done. Are we able to determine that strace or gdb have been explicitly started by the user rather than from some more confined application? We already block ptrace from almost every confined domain other then user domains. Ok, so if anything that's already a likely target of attack is unable to initiate ptrace or start a process that can ptrace, what real extra security do we gain by disabling it by default? AFAIK, firefox is not running in a confined domain, and that's a valuable target of attack. The same could be said of some others applications ( like acroread, etc ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On 9.4.2012 16:06, Jan Kratochvil wrote: Wouldn't it be better to package Mozilla plugins in Fedora so that they are trusted? And then disable Firefox plugins downloads the same way as there is Firefox updater disabled (--disable-updater) as it would conflict/duplicate the rpm packaging of Firefox anyway. Yes, it would be nice ... except there are so many addons to package (and some bugs which make it difficult to package Mozilla extensions as Fedora packages ... I cannot find them ATM in bugzilla.mozilla.org, but they are there). Observing a problems with maintaining only few Firefox addons we have already packaged for Fedora, doesn't give me much hope we can package a reasonable majority of addons Fedora users have installed. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On Tue, Apr 10, 2012 at 11:32 AM, Matej Cepl mc...@redhat.com wrote: On 9.4.2012 16:06, Jan Kratochvil wrote: Wouldn't it be better to package Mozilla plugins in Fedora so that they are trusted? And then disable Firefox plugins downloads the same way as there is Firefox updater disabled (--disable-updater) as it would conflict/duplicate the rpm packaging of Firefox anyway. Yes, it would be nice ... except there are so many addons to package (and some bugs which make it difficult to package Mozilla extensions as Fedora packages ... I cannot find them ATM in bugzilla.mozilla.org, but they are there). Observing a problems with maintaining only few Firefox addons we have already packaged for Fedora, doesn't give me much hope we can package a reasonable majority of addons Fedora users have installed. We don't even have a package installation gui that does not suck i.e is usable for most users. Going to a website and click install this addon is way easier from a users pov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On Tue, 10 Apr 2012 11:40:14 +0200, drago01 wrote: rpm packages do not magically fix security issues. A vulnerability in a plugin can be exploited by an attacker regardless how the plugin got installed. (rpm or not). This is still unrelated to the point whether Fedora is a Free distro or not (it is not due to Linux firmwares - this part is known). So why isn't Flash + acroread etc. also installed by default or be available in repositories? I still do not see the difference between Adobe software and Mozilla plugins. Or as a follow-up to Matej Cepl - do the U.S. laws apply to Mozilla and not to Adobe? Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On Tue, 10 Apr 2012 11:32:38 +0200, Matej Cepl wrote: Yes, it would be nice ... except there are so many addons to package Fedora also does not have about 2 packages that Debian has. Does it mean we should give up on Fedora and switch to Debian because we would have to make 2 packages otherwise? TBH I do not miss those 2 addon packages. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On Tue, 10 Apr 2012 11:37:58 +0200, drago01 wrote: We don't even have a package installation gui that does not suck i.e is usable for most users. Going to a website and click install this addon is way easier from a users pov. Keeping pre-installed MS-Windows on the computer is also way easier. I still do not see why to give up on Free distribution just because - we would have to make more packages, we would have to write better installer, what other reasons are there? Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/09/2012 10:00 PM, Kevin Kofler wrote: Daniel J Walsh wrote: We already block ptrace from almost every confined domain other then user domains. Then why not just keep it that way instead of breaking GDB? Kevin Kofler Because we are trying to protect the logged in user, where we currently do not confine that many domains, and even if you are using confined users we do not prevent a confined user process from ptrace on another user process, since they could be programmers of admin who need gdb or strace. I run always as staff_t but staff_t is allowed ptrace of staff_t, unless the deny_ptrace boolean is set. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/09/2012 09:58 PM, Kevin Kofler wrote: Matej Cepl wrote: I am afraid you are not an ordinary Fedora user. If abrt/breakpad/etc. works as they should, then I don't think majority of Fedora users have any reason why to pull out gdb at all. Because DrKonqi or some other similar crash handler (DrKonqi is not the only one which works like that) uses it. Kevin Kofler I have seen of gdm and NetworkManager execing gdb on crash. You keep saying other apps work like DrKonqi, can you give examples? I am wondering if we could break the ability to give a traceback from the ability to actually view and modify variables from an application. All of these apps seem to be just collecting a traceback, is DrKonqi collecting more? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Tue, 2012-04-10 at 04:04 +0200, Kevin Kofler wrote: Matej Cepl wrote: OK, this is bad ... is it just because somebody ignored DrKonqi (which would be very bad indeed) or are abrt and breakpad also affected? If Breakpad attaches GDB to live processes as DrKonqi does, it's also affected. As Rex said, ABRT is not affected because it attaches to core files instead. But DrKonqi (or any other debugger triggered by the crashing executable itself) cannot be easily changed to work on core files instead. ABRT works completely differently, by registering as the core file handler at kernel level instead. Abrt looks clearly a better solution. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Kevin Kofler píše v Út 10. 04. 2012 v 14:47 +0200: Daniel J Walsh wrote: I have seen of gdm and NetworkManager execing gdb on crash. You keep saying other apps work like DrKonqi, can you give examples? While unfortunately I don't know how all these work (i.e. whether they also work by execing GDB like DrKonqi) and while AFAIK not all of these are enabled in Fedora packaging, there are at least the following: * Breakpad (Mozilla) * Bug Buddy (GNOME, disabled in Fedora packaging AFAIK) * a crash handler in wxWidgets the internal crash handler in wxWidgets is disabled since F-14 Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Simo Sorce wrote: Abrt looks clearly a better solution. I disagree. From a technical standpoint, working on core files means you have to dump core and then attach to the core file after the fact when you could just backtrace right when the crash happened. A waste of disk space, and a security risk (you're making RAM contents persistent, and ABRT even allows you to upload them to a public bug tracker!). From a practical standpoint, ABRT is a distro-level solution which reports to the distro bug tracker rather than an upstream solution. Isn't Fedora about working with upstream? This also implies we need to triage all the ABRT bugs and forward them upstream (because the kind of users who files reports through ABRT most definitely won't report it upstream themselves). It also means that ABRT doesn't have access to the KAboutData information (application name, version, bug tracker or e-mail address to use etc.), whereas KCrash intercepts the crash from within the application (where that data is available) and passes all that information to DrKonqi. In my experience, bugs we receive from ABRT usually just bitrot, bugs filed upstream by DrKonqi stand a much higher chance to actually get fixed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Matej Cepl wrote: One good thing I would say about abrt is that it highly modular. Would output plugin file-the-bug-to-bugs.kde.org-or-somewhere-else be a solution for you? After all filing to bugzilla.redhat.com is just a matter of setting plugin for it ABRT does not have access to the required information from KAboutData. Where to file bugs (bugs.kde.org (automatic filing) or, for a third-party application using the KDE Platform, some e-mail address (fires up KMail with the report attached) or web site (you get a saved report, you have to click on the link in the dialog and attach the report manually)) and what bugs.kde.org component to use is encoded within the application. KCrash (the crash handler within the application) passes that information to DrKonqi on the command line. ABRT would probably need a static table with all this information encoded, and that cannot possibly be exhaustive for all the third-party KDE-Platform-based applications (nor the ones from extragear or playground at KDE), unless it can reliably be extracted from a core file. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Tue, Apr 10, 2012 at 11:27:12AM +0200, Michael Scherer wrote: Le mardi 10 avril 2012 à 02:57 +0100, Matthew Garrett a écrit : Ok, so if anything that's already a likely target of attack is unable to initiate ptrace or start a process that can ptrace, what real extra security do we gain by disabling it by default? AFAIK, firefox is not running in a confined domain, and that's a valuable target of attack. The same could be said of some others applications ( like acroread, etc ). Ok, so maybe we should talk about what an ideal world looks like, and then we can figure out how to get there. Aim: To prevent compromised applications using ptrace to obtain personal information from other applications, or to modify the behaviour of and so compromise other applications. Option 1: Disable ptrace globally. Breaks developer tools like gdb and strace, and certain crash reporting applications that either directly attach to an application to generate a backtrace or attach gdb to a running application to generate a backtrace. Option 2: Disable ptrace for everything except direct child processes. Allows the common case of running a task directly under a tool like gdb or strace, but forbids attaching one to an already running task. May break some of the same tools as option 1. Ubuntu defaults to this behaviour. Option 3: Have gdb and strace run in a specialised domain that permits ptrace, while forbidding it in general. Difficult at present because an attacker can just write out an attack binary and relabel it appropriately, or alternatively launch gdb directly and use it to perform the injection into another process. Option 4: Identify the set of most vulnerable applications, run them in confined domains and either forbid them access to ptrace or permit them only to ptrace children. Option 2 seems mildly preferable to option 1, but not significantly so. Option 3 seems unrealistic. Option 4 seems like it would benefit everyone without breaking anything, but is more work than the others. To a first approximation, simply auditing the distribution for anything that opens files or reads information from the network and forbidding them ptrace access (and denying ptrace access from any existing confined domains except, maybe, staff_t) seems like it would get us most of the way to option 4 without breaking existing user expectations. What am I missing that makes this infeasible? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
Jan Kratochvil wrote: This is still unrelated to the point whether Fedora is a Free distro or not (it is not due to Linux firmwares - this part is known). So why isn't Flash + acroread etc. also installed by default or be available in repositories? Because Fedora IS a Free Software distribution, with the exception of firmware, which is not considered software by Fedora because it does not run on the CPU. (And even for firmware, there are some terms which are not OK, like banning commercial use.) The FSF does not agree on the firmware issue, but that does not mean that Fedora's position is not consistent. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
drago01 wrote: We don't even have a package installation gui that does not suck i.e is usable for most users. Neither gnome-packagekit nor Apper suck. They're perfectly usable for most users. We just have a vocal minority of users who grew so accustomed to using the yum command line that they don't want to use ANY package installation GUI, no matter how well it works. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On Tue, 10 Apr 2012 15:07:45 +0200, Kevin Kofler wrote: Jan Kratochvil wrote: This is still unrelated to the point whether Fedora is a Free distro or not (it is not due to Linux firmwares - this part is known). So why isn't Flash + acroread etc. also installed by default or be available in repositories? Because Fedora IS a Free Software distribution, OK. So what is the difference that Mozilla plugins repository is preconfigured but RPMfusion/RPMforge/Adobe repositories are not preconfigured. I find these proprietary repositories have equal attributes, don't they? Either Fedora forbids accessibility of any non-Free software and therefore it should forbid also Mozilla plugins. Or Fedora is OK with installing non-Free software into it but then the Adobe repository should be made preconfigured because it is even significantly more convenient for end-user than the already preconfigured Mozilla repository. Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/09/2012 08:22 PM, Daniel J Walsh wrote: On 04/09/2012 02:15 PM, Miloslav Trmač wrote: On Mon, Apr 9, 2012 at 4:58 PM, Daniel J Walshdwa...@redhat.com wrote: One suggestion I have heard is to turn the feature off if someone install gdb like we do with DrKonji, which might be a better solution then disabling by default. It would be very surprising if merely installing a package changed the security configuration that is not directly related to the files installed by the package. Mirek Right, although this is about compromise. I want the feature for as many users as possible. We know, believe me... Do you want to know what *users* want? If I have it on, I will hit 90% of the installed SELinux Base. If I turn it off by default I will hit 1 % of the installed SELinux Base. If I compromise I can get 50 % of the installed base to use it. Poor installed base People do not tend to change the defaults when it comes to security other then loosening it. People also tend to remove handcuffs at every opportunity they get. I wonder why. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On 04/10/2012 09:24 AM, Jan Kratochvil wrote: On Tue, 10 Apr 2012 15:07:45 +0200, Kevin Kofler wrote: Jan Kratochvil wrote: This is still unrelated to the point whether Fedora is a Free distro or not (it is not due to Linux firmwares - this part is known). So why isn't Flash + acroread etc. also installed by default or be available in repositories? Because Fedora IS a Free Software distribution, OK. So what is the difference that Mozilla plugins repository is preconfigured but RPMfusion/RPMforge/Adobe repositories are not preconfigured. I find these proprietary repositories have equal attributes, don't they? Either Fedora forbids accessibility of any non-Free software and therefore it should forbid also Mozilla plugins. Or Fedora is OK with installing non-Free software into it but then the Adobe repository should be made preconfigured because it is even significantly more convenient for end-user than the already preconfigured Mozilla repository. Thanks, Jan Can we change the title on this conversation since it has nothing to do with the DenyPtrace feature. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Tue, 10 Apr 2012, Kevin Kofler wrote: From a technical standpoint, working on core files means you have to dump core and then attach to the core file after the fact when you could just backtrace right when the crash happened. A waste of disk space, and a security risk (you're making RAM contents persistent, and ABRT even allows you to upload them to a public bug tracker!). It could be written to tmpfs if you really think this is an issue. I see the crashing program as a bigger security risk than writing crash data my (encrypted) disk. From a practical standpoint, ABRT is a distro-level solution which reports to the distro bug tracker rather than an upstream solution. Isn't Fedora about working with upstream? This also implies we need to triage all the ABRT bugs and forward them upstream (because the kind of users who files reports through ABRT most definitely won't report it upstream themselves). I have been upstream for openswan for about 8 years, and I can tell you that the single reason for reporting bugs to upstream is if they really need to get openswan working and they can't. At most, they report straight into the RHBZ without ever bothering to contact upstream. It also means that ABRT doesn't have access to the KAboutData information (application name, version, bug tracker or e-mail address to use etc.), whereas KCrash intercepts the crash from within the application (where that data is available) and passes all that information to DrKonqi. In my experience, bugs we receive from ABRT usually just bitrot, bugs filed upstream by DrKonqi stand a much higher chance to actually get fixed. Again, as upstream, I'd rather not maintain my own separate automatic bug receiving, triaging duplicates and processing system. I think GUI apps have much different reporting profiles then other components, since they are affecting the user right there and then, and they can click to report with 0 effort. Count yourself lucky. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On Tue, 10 Apr 2012, drago01 wrote: Wouldn't it be better to package Mozilla plugins in Fedora so that they are trusted? rpm packages do not magically fix security issues. A vulnerability in a plugin can be exploited by an attacker regardless how the plugin got installed. (rpm or not). That's not true. SElinux could be used to restrict what a certain plugin could do when packages as rpm versus the SElinux properties of files in a users home directory. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Tue, Apr 10, 2012 at 11:26:50AM -0300, Horst H. von Brand wrote: Matthew Garrett mj...@srcf.ucam.org wrote: [...] To a first approximation, simply auditing the distribution for anything that opens files or reads information from the network and forbidding them ptrace access (and denying ptrace access from any existing confined domains except, maybe, staff_t) seems like it would get us most of the way to option 4 without breaking existing user expectations. What am I missing that makes this infeasible? That would leave just Hello, world! style programs (as long as they aren't in some way localized, like the GNU version is). Yeah, that's a bit broad. The 99% case would probably be anything that reads from the network or opens PDFs or doc files. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Hi Dan, On Mon, Apr 09, 2012 at 10:58:43AM -0400, Daniel J Walsh wrote: I thought I made this clear in my blogs and the feature page that I wanted this on deny_ptrace on by default. [...] We did have a bug in Alpha where it was turned off. Now that people are actually seeing it turned on in Fedora 17 Beta, they are reacting. My apologies I seem to react to this change so late. Now that I have seen your other blog postings I see that was your intention. But I did see the initial proposal and, like others, and FESCO, read it as making it an option that could be turned on. But not by default. Because that creates this situation that a normal users/developer needs to ask their admin to fix their machine even though they can write, compile and run their own programs, but suddenly aren't allowed to debug, profile or trace them. If I had thought it would be turned on by default, I would have spoken up sooner to try and help figure out something that wouldn't create such a disruption. If Fedora Board decides it should be turned off by default, I will of course abide by this decision. I could turn it off for Fedora 17 final and on in Rawhide to find other problems with the feature. That seems a good idea. But if you want, please lets discuss what this feature is really about and how we can give normal developers a good out of the box experience, that doesn't involve them having to unbreak their machine first before they can do their work. As I have stated in the blogs, this would be sad, since the goal of this feature is to protect the people who would never execute gdb -p, don't even know what gdb is. IE The vast majority of computer users. So we will make the system insecure for the majority who will never turn on security features, since they expect the machine to be secure by default, for the developers who know fully how to turn off the feature, so they will not be inconvenienced. I think it would set a bad precedent if we regard normal users as not being able or interested in development. Fedora needs developers to push forward. Also this suggests that if someone is a developer they should have lower security for their system, even for programs that we know we normally want to confine so they aren't able to do bad stuff. It really shouldn't matter that a user wants to run gdb, or some other introspection tool, on their system to make their firefox plugins a bigger security risk. Secondarily we do not know which software needs to be able to ptrace another process or what we get wrong with the feature without turning it on. But isn't this the wrong way around? Shouldn't you look for packages that don't need the ability and make sure they run in a restricted context so they cannot use features they don't want? What bothers me a bit is that you are restricting the unconfined user by default. Wasn't the purpose of the unconfined user to not be unecessarily be restricted by selinux? One suggestion I have heard is to turn the feature off if someone install gdb like we do with DrKonji, which might be a better solution then disabling by default. Although abrt-desktop seems to require gdb... And then also disable the feature system wide when installing strace, ltrace, perftools, or any other introspection tool that uses ptrace? But doesn't that mean that depending on which packages you happen have installed you get less security? Labeling an application and allowing a transition will not work as long as we have unconfined_t users. For example it has been suggested that we label certain apps like gdb or DrKonji as ptrace_exec_t and then transition when these apps get executed. Since an unconfined_t user can label any file as ptrace_exec_t and transition to the domains that allows ptrace. What are the applications we are worried about? And why don't we just run those in a context that has ptrace disabled? That is what normally happens with something like httpd isn't it? Changing the default user from unconfined_t to staff_t, would allow us to fix this problem, but I have a feeling the screaming about that would be overwhelming. Why would that not be a good solution? (That is a serious question, I don't really know too much about selinux.) Thanks, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On Tue, Apr 10, 2012 at 4:29 PM, Paul Wouters pwout...@redhat.com wrote: On Tue, 10 Apr 2012, drago01 wrote: Wouldn't it be better to package Mozilla plugins in Fedora so that they are trusted? rpm packages do not magically fix security issues. A vulnerability in a plugin can be exploited by an attacker regardless how the plugin got installed. (rpm or not). That's not true. SElinux could be used to restrict what a certain plugin could do when packages as rpm versus the SElinux properties of files in a users home directory. That's not true as well because plugins are libraries not binaries. You can confine the binary (like we did with nspluginwrapper in the past) regardless of where the plugin comes from. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/10/2012 09:04 AM, Matthew Garrett wrote: On Tue, Apr 10, 2012 at 11:27:12AM +0200, Michael Scherer wrote: Le mardi 10 avril 2012 à 02:57 +0100, Matthew Garrett a écrit : Ok, so if anything that's already a likely target of attack is unable to initiate ptrace or start a process that can ptrace, what real extra security do we gain by disabling it by default? AFAIK, firefox is not running in a confined domain, and that's a valuable target of attack. The same could be said of some others applications ( like acroread, etc ). Ok, so maybe we should talk about what an ideal world looks like, and then we can figure out how to get there. Aim: To prevent compromised applications using ptrace to obtain personal information from other applications, or to modify the behaviour of and so compromise other applications. Option 1: Disable ptrace globally. Breaks developer tools like gdb and strace, and certain crash reporting applications that either directly attach to an application to generate a backtrace or attach gdb to a running application to generate a backtrace. Option 2: Disable ptrace for everything except direct child processes. Allows the common case of running a task directly under a tool like gdb or strace, but forbids attaching one to an already running task. May break some of the same tools as option 1. Ubuntu defaults to this behaviour. I think this is still valuable since it can disable ptrace capability for all users, even though it will be disabled by default. Option 3: Have gdb and strace run in a specialised domain that permits ptrace, while forbidding it in general. Difficult at present because an attacker can just write out an attack binary and relabel it appropriately, or alternatively launch gdb directly and use it to perform the injection into another process. Option 4: Identify the set of most vulnerable applications, run them in confined domains and either forbid them access to ptrace or permit them only to ptrace children. Option 2 seems mildly preferable to option 1, but not significantly so. Option 3 seems unrealistic. Option 4 seems like it would benefit everyone without breaking anything, but is more work than the others. To a first approximation, simply auditing the distribution for anything that opens files or reads information from the network and forbidding them ptrace access (and denying ptrace access from any existing confined domains except, maybe, staff_t) seems like it would get us most of the way to option 4 without breaking existing user expectations. What am I missing that makes this infeasible? The problem with option 4 is that it is very difficult to do since the desktop is so connected. Say we isolate firefox_t as the same as unconfined_t without ptrace. firefox_t == unconfined_t -ptrace; firefox_t can start lots of helper apps, should the helper apps run as firefox_t or unconfined_t? If unconfined_t start office it runs as unconfined_t if firefox starts it, it runs as firefox_t, if unconfined_t office is running the firefox_t can cause it to open a new document, which could somehow trigger gdb... What about the dbus session bus, Can firefox_t start a gdb session via the session but to get around the confinement? This is why I developed sandbox, since the desktop was so interconnected trying to isolate permissions from apps such as chrome and firefox, is almost impossible without breaking critical functionality. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Niels de Vos wrote: It seems that there is prctl() call to allow a specific PID (like gdb stared by the signal-handler of DrKonqi) to trace the calling/crached process. The idea comes from following the gdb discussion here: - http://sourceware.org/ml/gdb-patches/2012-03/msg00274.html Indeed, I just checked: KCrash already implements this: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/54ec8be2d751c6954e96a6780995ab589702b1b0 so it's just a matter of SELinux understanding it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Mark Wielaard wrote: On Mon, Apr 09, 2012 at 10:58:43AM -0400, Daniel J Walsh wrote: I thought I made this clear in my blogs and the feature page that I wanted this on deny_ptrace on by default. [...] We did have a bug in Alpha where it was turned off. Now that people are actually seeing it turned on in Fedora 17 Beta, they are reacting. My apologies I seem to react to this change so late. Now that I have seen your other blog postings I see that was your intention. But I did see the initial proposal and, like others, and FESCO, read it as making it an option that could be turned on. But not by default. Because that creates this situation that a normal users/developer needs to ask their admin to fix their machine even though they can write, compile and run their own programs, but suddenly aren't allowed to debug, profile or trace them. If I had thought it would be turned on by default, I would have spoken up sooner to try and help figure out something that wouldn't create such a disruption. Not being able to get an strace from du or df (or several other programs in coreutils) would be a problem for me as coreutils maintainer. If someone is reporting strange behavior from those tools, it is common that the easiest way for us to diagnose the failure is by getting them to strace the program in their somehow-unusual environment. This situation arises once or twice a month, and the user reporting the problem might well not have root access to the system with the unusual file system or kernel. Admittedly, it hasn't happened much with Fedora recently, but with combinations of virtual machines and new file system types, we're far from seeing the last of those. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Paul Wouters wrote: I have been upstream for openswan for about 8 years, and I can tell you that the single reason for reporting bugs to upstream is if they really need to get openswan working and they can't. At most, they report straight into the RHBZ without ever bothering to contact upstream. That's exactly why we need the crash reporter to report directly upstream. (That said, when we ask users who file bugs manually to (re)file their bugs at bugs.kde.org, they usually do. But ABRT tends to be write-only, the users using that usually don't even reply to any requests for more information.) Again, as upstream, I'd rather not maintain my own separate automatic bug receiving, triaging duplicates and processing system. KDE upstream does maintain it and we should use it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On 04/10/2012 11:08 AM, drago01 wrote: On Tue, Apr 10, 2012 at 4:29 PM, Paul Wouters pwout...@redhat.com wrote: On Tue, 10 Apr 2012, drago01 wrote: Wouldn't it be better to package Mozilla plugins in Fedora so that they are trusted? rpm packages do not magically fix security issues. A vulnerability in a plugin can be exploited by an attacker regardless how the plugin got installed. (rpm or not). That's not true. SElinux could be used to restrict what a certain plugin could do when packages as rpm versus the SElinux properties of files in a users home directory. That's not true as well because plugins are libraries not binaries. You can confine the binary (like we did with nspluginwrapper in the past) regardless of where the plugin comes from. Correct SELinux can only confine a process. If a process loads a shared library and is running unconfined_t, there is nothing we can do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Tue, Apr 10, 2012 at 11:12:48AM -0400, Daniel J Walsh wrote: The problem with option 4 is that it is very difficult to do since the desktop is so connected. Say we isolate firefox_t as the same as unconfined_t without ptrace. Unless an app is current confined, I don't think there's a real need for app-specific domains - just an unconfined_except_ptrace_t one. firefox_t can start lots of helper apps, should the helper apps run as firefox_t or unconfined_t? If unconfined_t start office it runs as unconfined_t if firefox starts it, it runs as firefox_t, if unconfined_t office is running the firefox_t can cause it to open a new document, which could somehow trigger gdb... Helper apps would all be run in the same confined domain, unless they're more restricted? Libreoffice would be a prime example of an app that you'd want to be confined. What about the dbus session bus, Can firefox_t start a gdb session via the session but to get around the confinement? I don't think so, no. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Tue, Apr 10, 2012 at 07:47:25AM -0400, Daniel J Walsh wrote: Because we are trying to protect the logged in user, where we currently do not confine that many domains, and even if you are using confined users we do not prevent a confined user process from ptrace on another user process, since they could be programmers of admin who need gdb or strace. I run always as staff_t but staff_t is allowed ptrace of staff_t, unless the deny_ptrace boolean is set. Would it not be possible to wrap gdb/strace/etc. in something that presents a password prompt before switching to a context that's allowed to ptrace? Then it wouldn't be allowed to happen behind the users back, but still give all users the ability to ptrace. F.ex. something like a sudoers: ALL ALL=(ALL) TYPE=ptracer_t ROLE=ptrace_r PASSWD: /usr/bin/gdb, /usr/bin/strace ideally only unconfined_u, staff_u, sysadm_u and user_u should be allowed to do this. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 8.4.2012 22:50, Tom Lane wrote: And, as I said, the alternative is that this gets turned off, by me and probably a very large fraction of other Fedora users. Without getting into this discussion much, I would just note a bit of shocking news for you ... I am afraid you are not an ordinary Fedora user. If abrt/breakpad/etc. works as they should, then I don't think majority of Fedora users have any reason why to pull out gdb at all. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 9.4.2012 00:31, Kevin Kofler wrote: +1, this broken misfeature really needs to be turned off by default. It also breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by OK, this is bad ... is it just because somebody ignored DrKonqi (which would be very bad indeed) or are abrt and breakpad also affected? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Matej Cepl wrote: On 9.4.2012 00:31, Kevin Kofler wrote: +1, this broken misfeature really needs to be turned off by default. It also breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by OK, this is bad ... is it just because somebody ignored DrKonqi (which would be very bad indeed), Dan was made aware of the implications of breaking drkonqi, http://danwalsh.livejournal.com/49564.html (see comment DrKonqi, ABRT etc) and suggested we toggle the selinux boolean to disable it. or are abrt and breakpad also affected? abrt works differently (it works on .core files), and should be unaffected as I understand it. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Sun, Apr 08, 2012 at 07:02:31PM +0200, Mark Wielaard wrote: Previously https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace implied that this feature could be turned on by an administrator, but recently it was changed to be on by default. Was that intended? The change to selinux-policy was fairly recent (3.10.0-92) and seems to have taken at least some people by surprise. Fesco approved this feature with the understanding that it would be disabled by default. While some degree of scope creep is fairly common in the feature process, the feature as it exists now seems pretty different to what we approved. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Mon, 2012-04-09 at 00:31 +0200, Kevin Kofler wrote: It also breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by disabling the flag in kde-runtime's %post script, but there are other similar debuggers in upstream software, some not packaged in Fedora) I ask in the bug how DrKonqi works on other distros with the YAMA security module enabled which implements a slightly different semantic and didn't hear a response. I have patches which I will try to get into the Fedora kernel later today that will allow us to seamlessly allow gdb to trace children. gdb -p would still require disabling the boolean. (Think about it a moment. gdb -p is the same as firefox trying to ptrace gnome-keyring) My understanding is that DrKonqi wants to be able to ptrace anything run by the user. This is a scary idea. Please help me understand how DrKonqi works on other distros which limit how user applications are able to attack each other with the YAMA module and hopefully we can find a similar was to rectify the situation in Fedora. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/09/2012 11:11 AM, Frank Ch. Eigler wrote: dwalsh wrote: I thought I made this clear in my blogs and the feature page that I wanted this on deny_ptrace on by default. [...] https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace The version of this page that you last edited [1] (and presumably as seen by FESCO) had this blurb: The deny_ptrace boolean will deny all processes even the unconfined_t domain from being able to ptrace other domains. Because of this it will be optional and turned off by default which seems easy to interpret as the opposite of deny_ptrace on by default. [1] https://fedoraproject.org/w/index.php?title=Features/SELinuxDenyPtraceoldid=268413 - FChE Ok, I guess I will have to fix this, and propose that we turn it on by default in Fedora 18. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mozilla plugins packaging [Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?]
On Mon, 09 Apr 2012 17:56:06 +0200, Paul Wouters wrote: Only if you man the helpdesk for answering why users cannot install adblock in firefox. Do you mean mozilla-adblockplus-1.3.10-4.fc16.noarch? And if it is so wanted feature let it be installed in default Fedora installation and nobody will ask. This is what makes GNU/Linux easy - no need to spend time installing (and configuring) parts of it like in other OSes. You cannot take extension additions away from within firefox. People except that method to be available, and would not know to use the Fedora Package management system to install these. If they do not know how to use the Fedora Package management they cannot use Fedora. Unless you want to hack firefox so that add extension hooks into PackageKit and all. Sure that would be even better but I do not find it required. Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
2012/4/9 Daniel J Walsh dwa...@redhat.com On 04/09/2012 11:11 AM, Frank Ch. Eigler wrote: dwalsh wrote: I thought I made this clear in my blogs and the feature page that I wanted this on deny_ptrace on by default. [...] https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace The version of this page that you last edited [1] (and presumably as seen by FESCO) had this blurb: The deny_ptrace boolean will deny all processes even the unconfined_t domain from being able to ptrace other domains. Because of this it will be optional and turned off by default which seems easy to interpret as the opposite of deny_ptrace on by default. [1] https://fedoraproject.org/w/index.php?title=Features/SELinuxDenyPtraceoldid=268413 - FChE Ok, I guess I will have to fix this, and propose that we turn it on by default in Fedora 18. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Maybe if deny_ptrace remains turn on by default already from F17 is good, i think. Because of two reasons primarily: - Many Fedora normal users still don't know because SELinux is important, you image if someone be worried how to turn on a its boolean. - Although someone is interested to it, will think that it is not as important if disabled on default. Also: - If this feature is turned off by default, less feedbacks will come back from comunity. In any case i will advice to active it if necessary. My two cents. :) Regards. -- *Antonio Trande Fedora Ambassador **mail*: mailto:sagit...@fedoraproject.org sagit...@fedoraproject.org *Homepage*: http://www.fedora-os.org *Sip Address* : sip:sagitter AT ekiga.net *Jabber http://jabber.org/* :sagitter AT jabber.org *GPG Key: 19E6DF27* -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Mon, Apr 9, 2012 at 4:58 PM, Daniel J Walsh dwa...@redhat.com wrote: One suggestion I have heard is to turn the feature off if someone install gdb like we do with DrKonji, which might be a better solution then disabling by default. It would be very surprising if merely installing a package changed the security configuration that is not directly related to the files installed by the package. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/09/2012 02:15 PM, Miloslav Trmač wrote: On Mon, Apr 9, 2012 at 4:58 PM, Daniel J Walsh dwa...@redhat.com wrote: One suggestion I have heard is to turn the feature off if someone install gdb like we do with DrKonji, which might be a better solution then disabling by default. It would be very surprising if merely installing a package changed the security configuration that is not directly related to the files installed by the package. Mirek Right, although this is about compromise. I want the feature for as many users as possible. If I have it on, I will hit 90% of the installed SELinux Base. If I turn it off by default I will hit 1 % of the installed SELinux Base. If I compromise I can get 50 % of the installed base to use it. People do not tend to change the defaults when it comes to security other then loosening it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Mon, Apr 9, 2012 at 3:38 PM, Eric Paris epa...@redhat.com wrote: On Mon, 2012-04-09 at 00:31 +0200, Kevin Kofler wrote: It also breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by disabling the flag in kde-runtime's %post script, but there are other similar debuggers in upstream software, some not packaged in Fedora) I ask in the bug how DrKonqi works on other distros with the YAMA security module enabled which implements a slightly different semantic and didn't hear a response. I have patches which I will try to get into the Fedora kernel later today that will allow us to seamlessly allow gdb to trace children. gdb -p would still require disabling the boolean. (Think about it a moment. gdb -p is the same as firefox trying to ptrace gnome-keyring) My understanding is that DrKonqi wants to be able to ptrace anything run by the user. This is a scary idea. Please help me understand how DrKonqi works on other distros which limit how user applications are able to attack each other with the YAMA module and hopefully we can find a similar was to rectify the situation in Fedora. It seems that there is prctl() call to allow a specific PID (like gdb stared by the signal-handler of DrKonqi) to trace the calling/crached process. The idea comes from following the gdb discussion here: - http://sourceware.org/ml/gdb-patches/2012-03/msg00274.html HTH, Niels -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/09/2012 07:58 AM, Daniel J Walsh wrote: As I have stated in the blogs, this would be sad, since the goal of this feature is to protect the people who would never execute gdb -p, don't even know what gdb is. IE The vast majority of computer users. So we will make the system insecure for the majority who will never turn on security features, since they expect the machine to be secure by default, for the developers who know fully how to turn off the feature, so they will not be inconvenienced. As a developer of close-to-the-machine software, (C, assembler, debug-the- compiler's-code-generation, debug-the-debugger, debug-signal-handling, ...), I reasonably require gdb -p pid (PTRACE_ATTACH) to work. If you want to protect people, then figure out some way to protect them yet allow me to do my work on a usual multi-user system. There should be a per-process PtraceCapability which a child process inherits from its parent. Login removes PtraceCapability; then all PTRACE_* actions fail for that process and its children until the capability is enabled. SELinux allows some [site-dependent] UIDs/GUIDs to turn on PtraceCapability for a session; then all PTRACE_* actions for that session are governed by the old rule that UID of the target process must match the UID of the acting process, or the EUID of the actor must be 0 (root). -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
John Reiser wrote: I reasonably require gdb -p pid (PTRACE_ATTACH) to work. If you want to protect people, then figure out some way to protect them yet allow me to do my work on a usual multi-user system. They have figured out a way: It's controlled by a boolean. You can disable (or enable) this feature at any time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/09/2012 06:08 AM, Matej Cepl wrote: Without getting into this discussion much, I would just note a bit of shocking news for you ... I am afraid you are not an ordinary Fedora user. If abrt/breakpad/etc. works as they should, then I don't think majority of Fedora users have any reason why to pull out gdb at all. It's not just gdb: I use strace when applications have mysterious runtime problems of the type that outputs configuration error but doesn't say which file it is looking for or reading. Such introspection is one of the principal reasons Linux works better than the alternatives. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/09/2012 04:11 PM, Przemek Klosowski wrote: On 04/09/2012 06:08 AM, Matej Cepl wrote: Without getting into this discussion much, I would just note a bit of shocking news for you ... I am afraid you are not an ordinary Fedora user. If abrt/breakpad/etc. works as they should, then I don't think majority of Fedora users have any reason why to pull out gdb at all. It's not just gdb: I use strace when applications have mysterious runtime problems of the type that outputs configuration error but doesn't say which file it is looking for or reading. Such introspection is one of the principal reasons Linux works better than the alternatives. Yes we understand why ptrace and gdb and other stuff is good. We currently allow you to enable this by executing as root setsebool deny_ptrace 0 or if you want it permanantly disabled setsebool -P deny_ptrace 0 My argument is if you understand what ptrace or gdb are, you probably can figure out how to turn this feature off. And we are even putting information into the commands to tell you how to disable it. But for the vast majority of computer users who would what the hell strace, ptrace, gdb, DrKonqi are, we should disable the ability of any process on their desktop from being able to read/manipulate other processes on their desktop. And guess what I use these tools, and I just execute setsebool deny_ptrace 0 anytime I need to strace or debug an application, then I turn it back on when I am done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Mon, Apr 09, 2012 at 04:55:27PM -0400, Daniel J Walsh wrote: And guess what I use these tools, and I just execute setsebool deny_ptrace 0 anytime I need to strace or debug an application, then I turn it back on when I am done. Are we able to determine that strace or gdb have been explicitly started by the user rather than from some more confined application? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On 04/09/2012 05:06 PM, Matthew Garrett wrote: On Mon, Apr 09, 2012 at 04:55:27PM -0400, Daniel J Walsh wrote: And guess what I use these tools, and I just execute setsebool deny_ptrace 0 anytime I need to strace or debug an application, then I turn it back on when I am done. Are we able to determine that strace or gdb have been explicitly started by the user rather than from some more confined application? We already block ptrace from almost every confined domain other then user domains. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Daniel J Walsh wrote: We already block ptrace from almost every confined domain other then user domains. Then why not just keep it that way instead of breaking GDB? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Matej Cepl wrote: OK, this is bad ... is it just because somebody ignored DrKonqi (which would be very bad indeed) or are abrt and breakpad also affected? If Breakpad attaches GDB to live processes as DrKonqi does, it's also affected. As Rex said, ABRT is not affected because it attaches to core files instead. But DrKonqi (or any other debugger triggered by the crashing executable itself) cannot be easily changed to work on core files instead. ABRT works completely differently, by registering as the core file handler at kernel level instead. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Daniel J Walsh wrote: My argument is if you understand what ptrace or gdb are, you probably can figure out how to turn this feature off. And we are even putting information into the commands to tell you how to disable it. But for the vast majority of computer users who would what the hell strace, ptrace, gdb, DrKonqi are DrKonqi is a tool for ORDINARY users to reports crashes with backtraces to developers, just like ABRT is. You do not have to know what DrKonqi is to use it. Any KDE application that crashes triggers it automatically. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Eric Paris wrote: I ask in the bug how DrKonqi works on other distros with the YAMA security module enabled which implements a slightly different semantic and didn't hear a response. AFAIK, Kubuntu disables DrKonqi entirely, using Apport instead. But we don't want to do the same with ABRT in Fedora, mainly because ABRT reports to our Bugzilla and we want the crash bugs to go directly upstream instead. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Daniel J Walsh wrote: We did have a bug in Alpha where it was turned off. Now that people are actually seeing it turned on in Fedora 17 Beta, they are reacting. Uh no, I reacted back when you announced you would turn it on (which was also the first time I heard of the feature in the first place, since it wasn't discussed in the devel list, or at least not in the required level of detail to catch my attention, which your blog post did). If Fedora Board decides it should be turned off by default, I will of course abide by this decision. Shouldn't this be a FESCo decision rather than a Board decision? I could turn it off for Fedora 17 final and on in Rawhide to find other problems with the feature. Uh no, if the answer is you should turn it off, this means you should turn it off and keep it off. As I have stated in the blogs, this would be sad, since the goal of this feature is to protect the people who would never execute gdb -p, don't even know what gdb is. IE The vast majority of computer users. Again, there are many crash handlers for end users which run gdb -p internally. DrKonqi is just the most common one. So we will make the system insecure for the majority who will never turn on security features, since they expect the machine to be secure by default, for the developers who know fully how to turn off the feature, so they will not be inconvenienced. Those crash handlers are not only for developers. They're also for normal end users to report crashes to upstream developers. Secondarily we do not know which software needs to be able to ptrace another process or what we get wrong with the feature without turning it on. IE we did not know we broke DrKongi until we turned it on. Wrong. I told you that it'll break DrKonqi right when you said you were going to turn it on. I didn't even have to test it to know, it was obvious. (Though tests did confirm it. In fact there's a bug filed (#808372), also because the workaround you recommended to us, setting the boolean in the %post script, is racy: In the bug's case, selinux-policy was updated between kde-runtime updates, so the %post script never runs. There might also be other error conditions, e.g., selinux-policy getting upgraded only after kde-runtime in the same transaction. I guess a trigger would be more reliable. But the best solution would be to just have the boolean be off by default in the first place!) We are trying to figure out a fix for DrKonji, but have no feedback from these people other then we suck so turn it off. Lets work to figure out if we can do this feature with DrKonji. Because DrKonqi fundamentally does gdb -p, i.e. exactly what you don't want. The process GDB is going to be used on is its grandparent process (the parent of DrKonqi which is the parent of GDB). You'd have to allow at least tracing (grand)parent processes, but that'd probably allow attacking any process by going through parents and children in both directions. So I really don't see how DrKonqi and deny_ptrace can be made to work simultaenously. You blame me for saying that the feature is fundamentally incompatible with DrKonqi, but that's just shooting the messenger. I cannot give you any other solution because I can't think of any, and in fact I don't think such a solution even mathematically exists at all (though a rigorous proof would require fully formalizing all the premises). And I did answer all your questions about how DrKonqi works. One suggestion I have heard is to turn the feature off if someone install gdb like we do with DrKonji, which might be a better solution then disabling by default. I disagree. Changing booleans in RPM scriptlets is a hack, and it doesn't work reliably as evidenced by bug #808372. Although abrt-desktop seems to require gdb... … which also makes the idea of triggering this from gdb package scriptlets quite moot. Labeling an application and allowing a transition will not work as long as we have unconfined_t users. For example it has been suggested that we label certain apps like gdb or DrKonji as ptrace_exec_t and then transition when these apps get executed. Since an unconfined_t user can label any file as ptrace_exec_t and transition to the domains that allows ptrace. That's a fundamental flaw of the SELinux security model. Changing the default user from unconfined_t to staff_t, would allow us to fix this problem, but I have a feeling the screaming about that would be overwhelming. Indeed, that's even crazier than enabling deny_ptrace by default. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Michael Cronenworth wrote: John Reiser wrote: I reasonably require gdb -p pid (PTRACE_ATTACH) to work. If you want to protect people, then figure out some way to protect them yet allow me to do my work on a usual multi-user system. They have figured out a way: It's controlled by a boolean. You can disable (or enable) this feature at any time. Only root can do it on a usual multi-user system. He can't. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Mark Wielaard m...@redhat.com writes: Previously https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace implied that this feature could be turned on by an administrator, but recently it was changed to be on by default. Was that intended? I certainly hope that's a mistake. If it's not, I will gladly join the crowd of villagers with torches and pitchforks. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
I recently tested out f17 and saw I can no longer trace or debug applications by default. ... Is there still time to discuss and/or reconsider turning this on by default for F17? According to this bugzilla Comment https://bugzilla.redhat.com/show_bug.cgi?id=786878#c27 Fedora 17 Alpha turned on denyPtrace (as default) by mistake. According to other Comments to that same bug, the fix might involve allowing by default only PTRACE_ME, which then enables other PTRACE_* actions for the same (process, parent} pair. Apparently this will allow a debugger to ptrace a process that the debugger starts. I don't see that such a mechanism necessarily allows attaching a debugger to an existing non-child process, even if the other process has the same UID (which is the only requirement in Fedora 16 and previous.) gdb nicely gives the work-around for denyPtrace, but the work-around requires privileges to implement. So far the implementation history of the denyPtrace feature leads me to fear loss of Functionality and Usability for software developers. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
John Reiser jrei...@bitwagon.com writes: gdb nicely gives the work-around for denyPtrace, but the work-around requires privileges to implement. So far the implementation history of the denyPtrace feature leads me to fear loss of Functionality and Usability for software developers. Indeed. This feature isn't going to make people more secure if the first thing on everyone's Fedora installation checklist is to turn it off. And that certainly will be on my checklist, if it goes in like this. A possible compromise that might allow software developers to live with the setting would be if the default excluded gdb (and any other tools that normally need ptrace) from its effects. I can see the point of disallowing ptrace from security-exposed things like firefox, but I'm not very worried about gdb being compromised. And, as I said, the alternative is that this gets turned off, by me and probably a very large fraction of other Fedora users. How is that more secure? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
John Reiser jrei...@bitwagon.com writes: [...] According to this bugzilla Comment https://bugzilla.redhat.com/show_bug.cgi?id=786878#c27 Fedora 17 Alpha turned on denyPtrace (as default) by mistake. That's not how I read #c27. The flag was turned off during alpha by mistake and that it would be on in the beta, on purpose. It is the post-alpha pre-beta code that mjw and others have been testing. According to other Comments to that same bug, the fix might involve allowing by default only PTRACE_ME [...] That sounded all like future work. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Mark Wielaard wrote: Is there still time to discuss and/or reconsider turning this on by default for F17? +1, this broken misfeature really needs to be turned off by default. It also breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by disabling the flag in kde-runtime's %post script, but there are other similar debuggers in upstream software, some not packaged in Fedora), so the claim that it doesn't affect end users is blatantly false. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Sun, Apr 8, 2012 at 10:50 PM, Tom Lane t...@redhat.com wrote: And, as I said, the alternative is that this gets turned off, by me and probably a very large fraction of other Fedora users. How is that more secure? Perhaps people installing servers in high-risk situations could just not turn it off. OTOH in high-risk situations there are usually quite a few non-default settings, so that's not a great reason. I think a case can be made for disabling ptrace by default to protect ordinary users, at the cost of annoying developers or with one more step - but it's a weak case that would need much more discussion and experience than the originally proposed feature. Kevin's report that this breaks DrKonqi is a fairly good reason not to disable ptrace by default. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Sun, 08 Apr 2012 22:50:21 +0200, Tom Lane wrote: A possible compromise that might allow software developers to live with the setting would be if the default excluded gdb Counterargument in some that Bug was then the attacker can spawn GDB instead of using PTRACE_ATTACH in that process itself. SELinux tries to limit impact of an already exploited code so it is difficult to say what is right. The right is not to have any code exploitable. F-17 should at least bring it to the level of YAMA functionality: SELinux deny_ptrace: Do not restrict PTRACE_TRACEME [NEW] https://bugzilla.redhat.com/show_bug.cgi?id=802072 Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
