From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AB52E1396D0 for ; Thu, 24 Aug 2017 03:06:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B67DF1FC07C; Thu, 24 Aug 2017 03:06:37 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0B8E71FC019 for ; Thu, 24 Aug 2017 03:06:36 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dkiTS-0000Fd-K5 for gentoo-dev@lists.gentoo.org; Thu, 24 Aug 2017 05:06:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Guidelines for dangerous USE flags Date: Thu, 24 Aug 2017 03:06:13 +0000 (UTC) Message-ID: References: <17347fd7-d6ed-4c08-8d02-24df9237b576@gentoo.org> <20170822173751.GA18719@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.143 (Quaint little villages here and there; caf13eb07) X-Archives-Salt: 27d49f5a-49c6-4fe4-8712-8e7437d17f5f X-Archives-Hash: 4dfe94c80492f48582804e1e0bb1dde6 Sven Vermeulen posted on Tue, 22 Aug 2017 17:37:51 +0000 as excerpted: > On Tue, Aug 22, 2017 at 01:22:51PM -0400, Michael Orlitzky wrote: >> The net-analyzer/nrpe package has a ./configure flag: >> >> --enable-command-args allows clients to specify command arguments. >> *** THIS IS A SECURITY RISK! *** >> Read the SECURITY file before >> using this option! >> >> Back in nrpe-2.x, it was available via USE=command-args, but I dropped >> it from nrpe-3.x, and a user just asked about it (bug 628596). There >> are at least two things we could do with a dangerous flag like that: >> >> 1) require EXTRA_ECONF to enable it. >> 2) hide it behind a masked USE flag. >> >> Both options require about the same amount of work from the user, >> namely editing something under /etc/portage. What do y'all think is the >> best way to proceed? Are there other examples in the tree I could >> follow? > > I like the masked USE flag approach. Using EXTRA_ECONF requires a bit > more work from the user (not much though) but is less visible afterwards > in my opinion. > > Perhaps a name that implies that there is a security risk could be > interesting, but that's a minor suggestion. IDR which package it was on, but I remember investigating a USE flag called GAPING_SECURITY_HOLE or some such, on some package at some point. Turned out it was pretty much just that, but someone needed the feature it controlled on their firewalled LAN, and this flag is what the maintainer came up with as a solution. > Is there a way we could somehow ensure that a USE flag is never set > globally, but only on a per-package basis? The only mechanism I'm aware of for that, a hack but arguably an effective one, is including the package name in the USE flag. Combining all three suggestions, masked USE flag including the name of the package and a warning such as GAPING_SECURITY_HOLE (the ALL CAPS helps distinguish it too, since most USE flags are lowercase) in the name, say as ... nrpe-command-args-SECURITY-HOLE or just nrpe-GAPING-SECURITY-HOLE ... seems to me the most effective. Anyone that would even *think* to enable something like that without doing some *serious* investigation first, arguably shouldn't be using gentoo in the first place. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman