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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
