From owner-freebsd-security@FreeBSD.ORG Mon Feb 18 02:19:51 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E613316A417 for ; Mon, 18 Feb 2008 02:19:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A63B613C45A for ; Mon, 18 Feb 2008 02:19:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A36F546B7B; Sun, 17 Feb 2008 21:19:50 -0500 (EST) Date: Mon, 18 Feb 2008 02:19:50 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Borja Marcos In-Reply-To: Message-ID: <20080218021649.L96329@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-security@freebsd.org Subject: Re: MAC subsystem problem (FreeBSD 7) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 02:19:52 -0000 On Fri, 15 Feb 2008, Borja Marcos wrote: > I'm trying to set up a DNS server under FreeBSD using the mac_biba policy. I > use to run bind in low-integrity mode, so that neither it or any of its > descendants can modify configuration files, etc. > > With previous FreeBSD versions there was a handy sysctl setting, > "security.mac.enforce_socket" that allowed to bypass the MAC restrictions > for a socket. I think it's not a bad idea. After all machines can > communicate with untrusted nodes over a network. In my opinion, enforcing > the mac_biba restrictions so that a network communication with a local > process behaves _differently_ than a network communication with a different > node is a bad idea. > > Any reason why this setting has been eliminated? I think that the best > solution is to keep it and let the administrator decide. Borja, The interface was removed on the basis that it was a debugging setting, and in some cases can lead to the incorrect behavior of policies (for example, lomac, although not biba). The interface should actually be implemented within the policy so that policies still receive the entry points, but decide to ignore them for policy reasons, rather than preventing the entry points from being made to the policy. However, we can add them to individual policies, especially if they are useful. Could I ask you to file a PR for this issue, and forward me the PR receipt? I probably won't get to this for a week or two, but would be happy to investigate making the change to reintroduce object class controls of the same sort in biba (and the other policies). Just to be clear: the problem you're running into is that loopback network connections are controlled by biba, preventing certain loopback operations? Robert N M Watson Computer Laboratory University of Cambridge