From owner-freebsd-security@FreeBSD.ORG Thu Dec 3 16:49:26 2009 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 D64FC1065676 for ; Thu, 3 Dec 2009 16:49:26 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop2.sarenet.es (proxypop2.sarenet.es [194.30.0.95]) by mx1.freebsd.org (Postfix) with ESMTP id 97F078FC18 for ; Thu, 3 Dec 2009 16:49:26 +0000 (UTC) Received: from [172.16.1.204] (izaro.sarenet.es [192.148.167.11]) by proxypop2.sarenet.es (Postfix) with ESMTP id E407A7341F; Thu, 3 Dec 2009 17:49:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <3ACC849F-06CF-4BBD-88A5-7489D6DD75B4@sarenet.es> Date: Thu, 3 Dec 2009 17:49:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <200912010120.nB11Kjm9087476@freefall.freebsd.org> <4B17A0BE.9090502@fer.hr> <3ACC849F-06CF-4BBD-88A5-7489D6DD75B4@sarenet.es> To: Borja Marcos X-Mailer: Apple Mail (2.1077) Cc: freebsd-security@freebsd.org Subject: Re: rtld issue, MAC subsystem suggestion 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: Thu, 03 Dec 2009 16:49:26 -0000 On Dec 3, 2009, at 1:45 PM, Borja Marcos wrote: > There's a wrong assumption I made: the MAC subsystem should make a = root exploit hard to achieve, and the latest security issue shows that = indeed that's not necessarily the case. I chose not to chroot the = runnnig CGI's so that they saw a complete operating system, avoiding the = costs of lots of phone calls to support because their script got a text = file and ran awk on it, etc, etc, you know. Keeping lots of copies of = the OS is quite ineffective. And restricting access to mostly harmless = programs such as ping can be a problem as well. One of my compromises = (wrong, maybe) was to offer the closest thing to a complete system as = possible. Which brings an idea... I understand it might sound a bit ad-hoc after = this problem, but how about extending the usage of the MAC subsystem so = that MAC policies are enforced for such things as the dynamic linker? It = would certainly put a stop to a whole class of attacks. If a program with a given integrity label tried to link with a lower = integrity shared library maybe the operation should fail. Same should = apply to mac/mls.=20 I see no reason to allow that behavior to succeed, and plenty of reasons = for the MAC policies to be applied. Borja.