linux-kernel - Re: [PATCH] ptrace: allow restriction of ptrace scope

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Jun 2010 09:59:40 -0700
From:	Kees Cook <kees.cook@...onical.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Dave Young <hidave.darkstar@...il.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Howells <dhowells@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH] ptrace: allow restriction of ptrace scope

Hi,

On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote:
> Kees Cook <kees.cook@...onical.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.

> Either that or I can inject something nasty into the suid pulse-audio.

Hmm?

$ ls -la /usr/bin/pulseaudio
-rwxr-xr-x 1 root root 71712 2010-06-10 11:59 /usr/bin/pulseaudio

But I take your meaning to be "can still exploit other vulnerabilities".
That'll always be true, but that's why I'm looking to make the attack
surface smaller.

> I tell you what.  If you really want something effective, help Serge
> and I finish getting the cross namespace issues fixed for the user
> namespace.  When complete, it will possible for an unprivileged process
> to create a new one, and since kernel capabilities along with everything
> else will be local to it, running pidgin, or firefox, or another network
> facing potentially buggy application in such a namespace will ensure that
> even if the process is compromised it won't have privileges to ptrace another
> process or do much else on the system.

It sounds pretty good, but isolating desktop applications is no simple
task.  They tend to like to have free reign over a user's entire home
directory.  But I think that's a bit of a tangent.  That said, I'd like to
know more; where can I find details?

I'm all for better separations.  In fact, I'd like to see /proc/sys using
caps instead of DAC so that containers mounting /proc can't fiddle with the
entire system.  Has anyone done anything with this?  It seems like it's
only seen sporadic attention (e.g. my patch to test CAP_SYS_RAWIO for
changing mmap_min_addr).  I would assume there are others that need a
similar protection?

-Kees

-- 
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/