lkml.org 
[lkml]   [2010]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ptrace: allow restriction of ptrace scope
On Thu, Jun 17, 2010 at 01:45:02PM -0700, Eric W. Biederman wrote:
> Kees Cook <kees.cook@canonical.com> writes:
> > On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote:
> >> Kees Cook <kees.cook@canonical.com> writes:
> >> > running state of any of their processes. For example, if one application
> >> > (e.g. Pidgin) was compromised, it would be possible for an attacker to
> >> > attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
> >> > etc) to extract additional credentials and continue to expand the scope
> >> > of their attack without resorting to user-assisted phishing.
> >>
> >> This is ineffective. As an attacker after I gain access to a users
> >> system on ubuntu I can wait around until a package gets an update,
> >> and then run sudo and gain the power to do whatever I want.
> >
> > I doesn't stop phishing, correct. But it does stop immediate expansion of
> > an attack using already-existing credentials.
>
> sudo last I checked caches your password for a couple of seconds.
> So if you can probe the system to see when those couple of seconds
> are.

Sure, that's a downside of sudo, which is why privilege elevation has been
tending to move towards PolicyKit, FWIW.

> The archives of the containers list.
> https://lists.linux-foundation.org/pipermail/containers/ or just
> looking.

I'll go dig around.

> Things like /proc/sys/ will be default stay in the same user_namespace
> and root in other user namespaces will only get world permissions when
> accessing files.

Excellent. I'll move my questions about this to the containers mailing
list.

-Kees

--
Kees Cook
Ubuntu Security Team


\
 
 \ /
  Last update: 2010-06-17 23:19    [W:0.484 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site