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:	Wed, 16 Jun 2010 16:22:30 -0700
From:	Kees Cook <kees.cook@...onical.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH] ptrace: allow restriction of ptrace scope

Hi Alan,

On Thu, Jun 17, 2010 at 12:01:20AM +0100, Alan Cox wrote:
> > As Linux grows in popularity, it will become a larger target for
> > malware. One particularly troubling weakness of the Linux process
> > interfaces is that a single user is able to examine the memory and
> > running state of any of their processes. For example, if one application
> 
> And this will help how - or don't you care about procfs.

I'm not sure I follow this comment.  Sensitive things in /proc/$PID/* are
already protected by ptrace_may_access() with mode == ATTACH.

> Other distributions do this sensibly by using things like SELinux which
> can describe the relationships in ways that matter and also arbitrate
> other access paths beyond ptrace which can be used for the same purpose.

Certainly.  PTRACE can already be confined by SELinux and AppArmor.  I'm
looking for a general approach that doesn't require a system builder to
create MAC policies for unknown software.  I want to define a common core
behavior.

> And even if you don't care about using the same security stuff the rest
> of the world is using to solve the problem this like the other half baked
> stuff you posted for links belongs as a security module.

The LSM isn't stackable, so I can't put it there and choose this and
SELinux (for the case of software-without-a-policy).

> If you'd put it all in security/ubuntu/grsecurity or similar probably
> nobody would care too much. The hooks are there so you can do different
> things with security policy without making a mess for anyone else.

I'm not clear how this is "a mess for anyone else" when it defaults to
the classic PTRACE behavior.  PTRACE itself is dangerous, so it's not
unreasonable to start inching away from it.

> So NAK. If you want to use bits of grsecurity then please just write
> yourselves a grsecurity kernel module that uses the security hooks
> properly and stop messing up the core code. It's all really quite simple,
> the infrastrucuture is there, so use it.

There is no infrastructure to selectively choose these general-purpose
features.  This is why there is a sysctl.  It's a global behavioral
change.

Since LSMs aren't arbitrarily stackable, asking me to move the code into
a new LSM isn't a particularly actionable suggestion.

-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/