Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux