public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Guidelines for dangerous USE flags
Date: Thu, 24 Aug 2017 03:06:13 +0000 (UTC)	[thread overview]
Message-ID: <pan$31fa8$2869469$a0faf664$62b090b8@cox.net> (raw)
In-Reply-To: 20170822173751.GA18719@gentoo.org

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



  reply	other threads:[~2017-08-24  3:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-22 17:22 [gentoo-dev] Guidelines for dangerous USE flags Michael Orlitzky
2017-08-22 17:37 ` Sven Vermeulen
2017-08-24  3:06   ` Duncan [this message]
2017-08-29  9:21     ` [gentoo-dev] " Kent Fredric
2017-08-29 10:21       ` Duncan
2017-08-22 18:44 ` [gentoo-dev] " Robin H. Johnson
2017-08-24 15:22   ` Michael Orlitzky
2017-08-25 22:07     ` William Hubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$31fa8$2869469$a0faf664$62b090b8@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox