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:10:06 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
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>,
	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

This constraint seems fairly insane to me, but I don't really care about
people using sysctl to enable insane things if that's what floats your
boat.  GDB's "attach", "strace -p", etc. are pretty normal (and highly
useful) things for ordinary users debugging their own programs.

I tend to think that this constraint offers more a delusion of security
than much real protection.  But I'm too lazy to try to come up with a more
contorted exploit that this wouldn't prevent, so I won't belabor the point.

I think those who are actually paranoid would use something more meaningful
via the LSM ptrace check, like SELinux with a policy that only permits
known debugger applications to use ptrace.  Aside from SELinux, it could
also be done with a new capability like CAP_PTRACE_MINE and filesystem
capabilities on installed debugger application binaries, for example.

You've described this as allowing ptrace on "children", but really it's
"unorphaned descendants", i.e. also children of children, etc.

I don't think "task->pid > 0" is a sort of check that is used elsewhere in
the kernel for this.  Perhaps "task == &init_task" would be better.

It's not immediately obvious to me how this interacts with pid_ns, or
should.  Probably it shouldn't pay attention to pid_ns, as it doesn't.
But I think it merits an explicit statement of intent about that.

I suspect you really want to test same_thread_group(walker, current).
You don't actually mean to rule out a debugger that forks children with
one thread and calls ptrace with another, do you?

Oh, and surely you meant real_parent.  Off hand I think that might only
really add up to a different constraint if you had some ptrace attaches
already live when you did set the sysctl flag.  But I have the vague
sensation I'm overlooking some other arcane case.  And it just doesn't
logically match the stated intent of the thing to depend on parent
rather than real_parent.

Thanks,
Roland
--
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/