From owner-freebsd-current@FreeBSD.ORG Mon Jun 16 18:10:18 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E71D1065677 for ; Mon, 16 Jun 2008 18:10:18 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9D58FC14 for ; Mon, 16 Jun 2008 18:10:18 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by an-out-0708.google.com with SMTP id b33so1277610ana.13 for ; Mon, 16 Jun 2008 11:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=0zTsS4XVaSqfCT5d99Zyz7Lb//wkcNuHqPtKgvTJnXs=; b=j5IC5ChTIXJ02hbzyu4bs/wn9iX2SannDhnXUVEZvEZL3TcWwZ/4KOrmj2RvgSiL1K dYtmTfx7zYE2m5NhiAhwjEl7EGUIHkWLDlJlYbF9ri/35b7P9VSDNQFmeLB4kocO2NCy PbJVx+dyplAUpGOePR3JajvG8Wy7UP0W6Z7HI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=wFQpo81CaNg4NCBJXNOrmq89Uv9ZAUo7KIBJiA0EJAo8s9AJNHTtilCcF5E1BIDqjQ noH40dY/BTp799Wyxv/JIyhg8FMVGapto9RcbJNbk7Tu4LGU/3fH64lUKZsE4OYRPRuN 4cenUfobUC8srYuuMKxzYBXdV3d5FFOvGa1QQ= Received: by 10.100.228.17 with SMTP id a17mr7573142anh.116.1213639817391; Mon, 16 Jun 2008 11:10:17 -0700 (PDT) Received: by 10.100.135.19 with HTTP; Mon, 16 Jun 2008 11:10:17 -0700 (PDT) Message-ID: Date: Mon, 16 Jun 2008 19:10:17 +0100 From: "Rui Paulo" Sender: rpaulo@gmail.com To: "Stanislav Sedov" In-Reply-To: <20080616204433.48ad9879.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080606020927.8d6675e1.stas@FreeBSD.org> <10261.1212703949@critter.freebsd.dk> <20080606025533.8322ee08.stas@FreeBSD.org> <1212758604.1904.33.camel@localhost> <20080615230250.7f3efae4.stas@FreeBSD.org> <1213557999.1816.15.camel@localhost> <20080616204433.48ad9879.stas@FreeBSD.org> X-Google-Sender-Auth: cb033783cf48c6af Cc: Peter Jeremy , Poul-Henning Kamp , kib@freebsd.org, current@freebsd.org, Coleman Kane Subject: Re: cpuctl(formely devcpu) patch test request 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: Mon, 16 Jun 2008 18:10:18 -0000 On Mon, Jun 16, 2008 at 5:44 PM, Stanislav Sedov wrote: > On Sun, 15 Jun 2008 15:26:39 -0400 > Coleman Kane mentioned: > >> I think the anti-foot-shooting measures referred to above were also >> taking into consideration for security reasons. It might be valuable for >> someone to be able to configure this feature to be rdmsr-only, thereby >> limiting potential harm vectors in the event that an attacker is likely >> to crack access to the system for supervisory privileges. This would be >> a legitimate consideration to make, especially so that the module could >> at least provide a sane "safe operating mode" to those that would >> benefit from read-only access. >> >> So, for example, I would consider most crackers to be skilled enough to >> inject an ioctl call somewhere, even if the primary user of the system >> is not so skilled., but they want to use software written by others that >> makes use of this interface. > > On the other hand, providing extra security levels via sysctl looks > slightly overkill to me, as if the attacker would be able to issue > a ioctl call somewhere it would be easy to him to make a sysctl > call as well. Priv(9) checks and/or securelevels could be used > to limit the usage of this functionality. Furthermore, there're > a lot of other possible ways to execure an msr instructions, > including loading your own simple kernel object. There's no security issue here. If the system administrator is concerned about "security" of cpuctl, he/she just has to compile-out cpuctl or remove the module from the file system. Regards, -- Rui Paulo