linux-kernel - setrlimit(RLIMIT_NETWORK) vs. prctl(???)

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: <20091213050900.GC4369@heat>
Date:	Sun, 13 Dec 2009 00:09:00 -0500
From:	Michael Stone <michael@...top.org>
To:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-security-module@...r.kernel.org
Cc:	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>,
	Rémi Denis-Courmont <rdenis@...phalempin.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>,
	Mark Seaborn <mrs@...hic-beasts.com>,
	Michael Stone <michael@...top.org>
Subject: setrlimit(RLIMIT_NETWORK) vs. prctl(???)

Folks,

A colleague just asked me an excellent question about my approach which I'd
like to share with you. Paraphrasing, he wrote:

> rlimits seem very heavy for a simple inherited boolean flag. Also, creating
> a new one will require modifying a lot of delicate userland software.
> Wouldn't some new prctl() flags be a better choice?

Here's my response:

> You're absolutely right that choosing to expose this functionality as an
> rlimit (as opposed to as a new syscall or as a flag to an old syscall like
> prctl()) is a decision with complex consequences.
> 
> I picked rlimits for this patch (after trying the "new syscall" approach
> privately) because doing so provides exactly the interface, semantics, and
> userland integration that I want:
>
> interface: "unprivileged", "temporarily drop", "permanently drop", "get
> current state", "persist current state across exec()", and some room for
> future expansion of semantics by definining new state values between 0 and
> RLIMIT_INFINITY.
> 
> integration: lots of sandboxing code already contains logic to drop rlimits
> when starting up an isolated process. Furthermore, I think it would be really
> great to be able to limit networking from the shell via ulimit and on a
> per-user basis via /etc/security/limits.conf.
> 
> That being said, I'm not wedded to the decision. Could you give me some more
> specific examples of the kinds of changes in low-level userspace code that
> you're worried about?

Regards,

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