From patchwork Fri Dec 5 14:12:19 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Smalley X-Patchwork-Id: 12405 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 13A14DDDE7 for ; Sat, 6 Dec 2008 01:15:18 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751943AbYLEOPN (ORCPT ); Fri, 5 Dec 2008 09:15:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751775AbYLEOPN (ORCPT ); Fri, 5 Dec 2008 09:15:13 -0500 Received: from mummy.ncsc.mil ([144.51.88.129]:45976 "EHLO mummy.ncsc.mil" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751620AbYLEOPL (ORCPT ); Fri, 5 Dec 2008 09:15:11 -0500 Received: from tarius.tycho.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id mB5EEG8J012890; Fri, 5 Dec 2008 14:14:17 GMT Received: from [144.51.25.121] (moss-spartans [144.51.25.121]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id mB5EEF0V018211; Fri, 5 Dec 2008 09:14:15 -0500 Subject: Re: [E1000-devel] networking probs in next-20081203 From: Stephen Smalley To: "Eric W. Biederman" Cc: David Miller , adobriyan@gmail.com, auke-jan.h.kok@intel.com, akpm@linux-foundation.org, e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org, jmorris@namei.org, eparis@parisplace.org In-Reply-To: References: <49381644.8020502@intel.com> <20081204175236.GA19808@x200.localdomain> <1228414280.11091.54.camel@moss-spartans.epoch.ncsc.mil> <20081204.102138.123959105.davem@davemloft.net> <1228419142.11091.90.camel@moss-spartans.epoch.ncsc.mil> <1228421219.11091.94.camel@moss-spartans.epoch.ncsc.mil> Organization: National Security Agency Date: Fri, 05 Dec 2008 09:12:19 -0500 Message-Id: <1228486339.20274.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 (2.24.2-1.fc10) X-Spam-Status: No, score=-103.7 required=3.5 tests=ALL_TRUSTED, AWL, BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tarius.tycho.ncsc.mil Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 2008-12-04 at 13:00 -0800, Eric W. Biederman wrote: > Stephen Smalley writes: > > > On Thu, 2008-12-04 at 14:32 -0500, Stephen Smalley wrote: > >> On Thu, 2008-12-04 at 10:21 -0800, David Miller wrote: > >> > From: Stephen Smalley > >> > Date: Thu, 04 Dec 2008 13:11:20 -0500 > >> > > >> > > On Thu, 2008-12-04 at 20:52 +0300, Alexey Dobriyan wrote: > >> > > > On Thu, Dec 04, 2008 at 09:41:24AM -0800, Kok, Auke wrote: > >> > > > > maybe try disabling selinux? > >> > > > > >> > > > This will work. :^) > >> > > > >> > > SELinux didn't change here. /proc/net did. > >> > > >> > We've been through this before... > >> > >> Yep, and we altered SELinux so that they could freely change proc > >> directories into symlinks to support the earlier proc/net change. But > >> now proc/net has turned into its own separate filesystem, with its own > >> filesystem type, which is unknown to SELinux. Thus causing it to be > >> left unlabeled and inaccessible to confined domains. > >> > >> > And it is a usability issue that people can't change how procfs > >> > directories work without requiring the user to update their selinux > >> > policies first. > >> > >> Introducing a new filesystem type (proc/net) without teaching SELinux > >> how to handle it is always going to produce denials on accessing that > >> filesystem. If they left the filesystem type string as "proc" it > >> wouldn't be a problem. > > > > Actually, that isn't quite correct as it wouldn't generate the same > > name/key for lookup. > > > >> Or they can adjust the SELinux code to > >> automagically handle it. Regardless, we didn't break anything. > > > > Looking back, I see that they did in fact change selinux as part of the > > patch to make proc/net its own filesystem, although unfortunately not in > > a way that will quite work. But no selinux maintainer was ever cc'd on > > that patch. > > Yes. Apologies. The whole thing started with some stupid security > drama and so things tried to happen outside of the normal channels > and things just went wrong, and got lost... > > When I resent and started things through the normal channels I forgot > to cc you guys. My apologies. > > Which piece of selinux magic did I miss? > > In particular can you tell if this was a code bug or a logic bug? I suspect we need the following un-tested diff to map all of these proc/ filesystem types to "proc" for the policy lookup at filesystem mount time. diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 9155fa9..3c3ceb7 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -703,7 +703,7 @@ static int selinux_set_mnt_opts(struct super_block *sb, sbsec->proc = 1; /* Determine the labeling behavior to use for this filesystem type. */ - rc = security_fs_use(sb->s_type->name, &sbsec->behavior, &sbsec->sid); + rc = security_fs_use(sbsec->proc ? "proc" : sb->s_type->name, &sbsec->behavior, &sbsec->sid); if (rc) { printk(KERN_WARNING "%s: security_fs_use(%s) returned %d\n", __func__, sb->s_type->name, rc);