Messages in this thread | | | Date | Thu, 17 Jun 2010 14:14:41 -0700 | From | Kees Cook <> | Subject | Re: [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
| |