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 for Android: free password hash cracker in your pocket

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

Message-ID: <20100617000120.13071be8@lxorguk.ukuu.org.uk>
Date:	Thu, 17 Jun 2010 00:01:20 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Kees Cook <kees.cook@...onical.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>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH] ptrace: allow restriction of ptrace scope

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

> +	/* require ptrace target be a child of ptracer on attach */
> +	if (mode == PTRACE_MODE_ATTACH && ptrace_scope &&
> +	    !capable(CAP_SYS_PTRACE)) {
> +		struct task_struct *walker = task;
> +		int rc = 0;
> +
> +		read_lock(&tasklist_lock);
> +		while (walker->pid > 0) {
> +			if (walker == current)
> +				break;
> +			walker = walker->parent;
> +		}
> +		if (walker->pid == 0)
> +			rc = -EPERM;
> +		read_unlock(&tasklist_lock);
> +		if (rc)
> +			return rc;
> +	}

But even if it wasn't pointless this would be the wrong way to do it.

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.

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.

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.

See ptrace_access_check, ptrace_traceme, and do remember /proc/mem -
which you'll find if you use the proper security hooks is already covered
for you.

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.

Alan

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