linux-kernel - Re: [PATCH] Security: Add prctl(PR_{GET,SET}

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]

Message-ID: <fb69ef3c0912200953x2546f03cs5a88c9a54fd750ee@mail.gmail.com>
Date:	Sun, 20 Dec 2009 17:53:58 +0000
From:	Mark Seaborn <mrs@...hic-beasts.com>
To:	Michael Stone <michael@...top.org>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>, David Lang <david@...g.hm>,
	Oliver Hartkopp <socketcan@...tkopp.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	Bryan Donlan <bdonlan@...il.com>,
	Evgeniy Polyakov <zbr@...emap.net>,
	"C. Scott Ananian" <cscott@...ott.net>,
	James Morris <jmorris@...ei.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Bernie Innocenti <bernie@...ewiz.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Américo Wang <xiyou.wangcong@...il.com>
Subject: Re: [PATCH] Security: Add prctl(PR_{GET,SET}_NETWORK) interface.

On Fri, Dec 18, 2009 at 3:00 AM, Michael Stone <michael@...top.org> wrote:

> @Eric, Mark: regarding ptrace()-ing from network-disabled processes: I agree
> that this functionality is critical and I have altered the
> __ptrace_may_access() check to support it.
> The new rule I propose is equivalent to the rule I used in ptrace_set_network()
> and is similar to the rule that Eric proposed earlier this afternoon. I now
> propose:
>
>  "You may ptrace() any process that has all the network restrictions you do."
>
> This should take care of your use of strace without bending anything else into
> an unnatural shape.

I am in two minds about this.  On the one hand, it adds the
flexibility that I asked for.  On the other hand, it is a more
complicated rule to have fixed in the kernel.

It still seems wrong to me that the disable-networking flag should
affect ptrace() at all.

The reason is that the disable-networking flag is not useful on its
own.  Anyone who uses it will use it in combination with some other
authority-limiting mechanism.  They will already have a story for how
to prevent sandboxed processes with interfering with other processes
via ptrace(), kill(), writing to ~/.bashrc, etc.  There's no point in
disabling network access for a process if it has full access to your
home directory and can cause programs to be run with your full
authority as a user.

So if there is already a way to control access to ptrace(), we
shouldn't add another check to the kernel's access control rules.
They are complicated enough already.

On ad-hocness: I am very much in favour of providing unprivileged
mechanisms for switching off sources of ambient authority.  But it
does not seem very useful to provide an unprivileged mechanism to
switch off network access if there is no unprivileged mechanism for
switching off access to the filesystem namespace, which is usually a
more important source of authority.  Maybe we should solve both
problems?

Cheers,
Mark
--
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/