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.