From owner-freebsd-current@FreeBSD.ORG Wed Feb 29 18:00:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C541F1065686 for ; Wed, 29 Feb 2012 18:00:17 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5C38FC19 for ; Wed, 29 Feb 2012 18:00:17 +0000 (UTC) Received: by yenq7 with SMTP id q7so1777832yen.13 for ; Wed, 29 Feb 2012 10:00:16 -0800 (PST) Received-SPF: pass (google.com: domain of jhellenthal@dataix.net designates 10.50.193.199 as permitted sender) client-ip=10.50.193.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jhellenthal@dataix.net designates 10.50.193.199 as permitted sender) smtp.mail=jhellenthal@dataix.net; dkim=pass header.i=jhellenthal@dataix.net Received: from mr.google.com ([10.50.193.199]) by 10.50.193.199 with SMTP id hq7mr1672618igc.4.1330538416574 (num_hops = 1); Wed, 29 Feb 2012 10:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=PDgGjdkymHlpBYNe6jD2bECPfsB2gSthHZu8WoqzEbQ=; b=SJpW0fh2t+w51QQtQ776hZpTi9Fct2cxkBLzMnZkcPftY680pw4vKe6T1pgldWvIia 4sAkRWYbU9MHRBGZUCdQaGXl4b7ivw+jzQPPrYFBjhk8JkyW5Rwl2CLCk57nApDBgldS wJocuNTvnQ0fPVUGtbmN+3S6Ogk3Tk40qf2Fg= Received: by 10.50.193.199 with SMTP id hq7mr1363191igc.4.1330538416375; Wed, 29 Feb 2012 10:00:16 -0800 (PST) Received: from DataIX.net (adsl-99-181-159-39.dsl.klmzmi.sbcglobal.net. [99.181.159.39]) by mx.google.com with ESMTPS id ch2sm17318294igb.4.2012.02.29.10.00.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 10:00:15 -0800 (PST) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1TI0CR5035665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Feb 2012 13:00:12 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1TI0BH7008612; Wed, 29 Feb 2012 13:00:11 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Date: Wed, 29 Feb 2012 13:00:11 -0500 From: Jason Hellenthal To: Ian Lepore Message-ID: <20120229180010.GA93342@DataIX.net> References: <20120228162447.GB58311@mech-cluster241.men.bris.ac.uk> <20120229072458.GA95427@DataIX.net> <20120229085716.GA66484@mech-cluster241.men.bris.ac.uk> <1330527621.1023.27.camel@revolution.hippie.lan> <20120229164115.GB64201@DataIX.net> <1330535893.1023.49.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1330535893.1023.49.camel@revolution.hippie.lan> X-Gm-Message-State: ALoCoQna5TTlxtmj95Xoel6r5AAlIDhfHowe9eaUiropd1EIe0spROjHNJ/oWXdaB79sf7NsV2Ij Cc: freebsd-current@freebsd.org, jb Subject: Re: negative group permissions? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:00:17 -0000 On Wed, Feb 29, 2012 at 10:18:13AM -0700, Ian Lepore wrote: > On Wed, 2012-02-29 at 11:41 -0500, Jason Hellenthal wrote: > > > > On Wed, Feb 29, 2012 at 04:18:45PM +0000, jb wrote: > > > Ian Lepore damnhippie.dyndns.org> writes: > > > > > > > ... > > > > It's not a > > > > directory or executable file in the first place, so making it executable > > > > for everyone except the owner and group is not some sort of subtle > > > > security trick, it's just meaningless. > > > > ... > > > > > > Is it meaningless ? > > > > > > Example: > > > # cat /var/spool/output/lpd/.seq > > > #! /usr/local/bin/bash > > > touch /tmp/jb-test-`echo $$` > > > > > > # ls -al /var/spool/output/lpd/.seq > > > -rw-r----x 1 root daemon 54 Feb 29 17:05 /var/spool/output/lpd/.seq > > > # /var/spool/output/lpd/.seq > > > # > > > # ls /tmp/jb* > > > /tmp/jb-test-61789 > > > > > > # chmod 0640 /var/spool/output/lpd/.seq > > > # ls -al /var/spool/output/lpd/.seq > > > -rw-r----- 1 root daemon 52 Feb 29 17:11 /var/spool/output/lpd/.seq > > > # /var/spool/output/lpd/.seq > > > su: /var/spool/output/lpd/.seq: Permission denied > > > # > > > > > > > Giving execute bit to others by security means to allow others to search > > for that file and find it. If its not there then the process created by > > current user will not be able to read the file since they are not part > > of the daemon group. I would assume that sometimes the contents of .seq > > was judged to be insecure for whatever reason but judged that a user > > should be able to still in a sense read the file without reading its > > contents. Negative perms are not harmful. > > > > I do suppose a 'daily_status_security_neggrpperm_dirs=' variable should > > be added here to control which directories are being scanned much like > > chknoid. > > > > The exec bit's control over the ability to search applies to > directories, not individual files. For example: > > revolution > whoami > ilepore > revolution > ll /tmp/test > -rw-r----x 1 root daemon 0B Feb 29 07:37 /tmp/test* > > The file is 0641 and I'm not in the daemon group; I can list it. > The issue is not with listing the file. Setting the execute bit on a file where there is only a read bit higher up allows for the calling process to read the contents and noone else. This is special and not a flaw. > Again, the problem here seems to be the use of 0661 in the lpr program, > not the idea of negative permissions, not the new scan for the use of > negative permissions. It's just an old bug in an old program which used > to be harmless and now is "mostly harmless". Instead of trying to "fix" > it by causing the new scan to ignore it, why don't we fix it by fixing > the program? (I'd submit a patch but it's a 1-character change -- it's > not clear to me a patch would be easier for a commiter to handle than > just finding and changing the only occurrance of "0661" in lpr.c.) > It was intentional and not a flaw. This file should be readable by the calling process and noone else. This is the way permissions work. -- ;s =;