From owner-freebsd-scsi@freebsd.org Fri Feb 23 17:20:17 2018 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68E3FF0955B; Fri, 23 Feb 2018 17:20:17 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FB356BB10; Fri, 23 Feb 2018 17:20:16 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 41D0120DEF; Fri, 23 Feb 2018 12:20:16 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 23 Feb 2018 12:20:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=aa7E32sIwFgGFeLpavYUxwt2Crwtk qZbaz2H6Byp6PU=; b=j3f4gwivZqZ0H+3z8LkCKUpJEegYJ4e225EVCeHUPLxjg 92Q9xCCU1c0b6frcBop6OEF+J4JuVvnAgJ0656UoJSrivbJe9NCQRyQ+toozvHK5 4FyozhZKMASLDPz+mkw1rSB/si5tEeKH7WF74k2qZAlz7R+XcIAuV7QetM62BKbB 5GLhpNZ0g9Cqm1TB4as3EnB3KXoplhoaTtPA0SnYpF4OMpDcEoo0Eq/IxpcUQ199 1Z05W9eLLtyNVkcVY/vMSXh7gaGrLdcWKc81SiwqVWXrcX7d7Ka9gCUDEQbg3tY2 KvEF5Nsz16uonbF5ZMmFmBdygnjzrI3Ogp+bXmj3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=aa7E32 sIwFgGFeLpavYUxwt2CrwtkqZbaz2H6Byp6PU=; b=cilkwhIlfhQ8iyuxaU8BRW QpKE9kFRoxlFWw/r7TS2zjXCnqXTW+rvtRuhZ6m9nK8xidANywjWkaQJLsPdm/5m 0qO7eWIvBf/60KlEcLoOvXfDdjK+zWniuHmDoTKChCOr1PhAjZ0IGF7/+U05jOJV l8BmIQQYILV/NivIRMqXaWeR01hn9xtX8tpE1WCFarA7yco2qNaQdstaFRld3QmC v9kHq1039AB3BOkwCIVtBmvob16gZbR9Eq7obfEZhmsRiOOVwWxgLPmeRhQ8xb4G 5NpSpbsWGNVI+TrUPJUgPhIcyU2Z5o60j7AeBazvl3+jaj7yQxwvi2OUxUbmqRCQ == X-ME-Sender: Received: from [192.168.0.116] (unknown [161.97.249.191]) by mail.messagingengine.com (Postfix) with ESMTPA id AC3C7240B6; Fri, 23 Feb 2018 12:20:15 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: smartmontools and kern.securelevel From: Scott Long In-Reply-To: <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> Date: Fri, 23 Feb 2018 10:20:12 -0700 Cc: Warner Losh , Freebsd fs , FreeBSD-scsi Content-Transfer-Encoding: quoted-printable Message-Id: References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> To: Ben RUBSON X-Mailer: Apple Mail (2.3445.4.7) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 17:20:17 -0000 > On Feb 23, 2018, at 9:46 AM, Ben RUBSON wrote: >=20 > On 23 Feb 2018, Warner Losh wrote: >=20 >> On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON = wrote: >>=20 >>> Hi, >>>=20 >>> I run smartmontools on my storage servers, to launch periodic disk = tests and alert on disk errors. >>>=20 >>> Unfortunately, if we set sysctl kern.securelevel >=3D2, = smartmontools does not work anymore. >>> Certainly because it needs to write directly to raw devices. >>> (details of the levels, -1 to 3, in security(7)) >>>=20 >>> Any workaround to this ? >>>=20 >>> Perhaps we could think about allowing SMART commands to be written = to disks when sysctl kern.securelevel >=3D2 ? >>> (I assume smartmontools writes SMART commands) >>=20 >> Sending raw disks commands is inherently insecure. It's hard to = create a list of those commands that are OK because of the complexity = and diversity of the needed functionality. That complexity also makes it = hard to put the commands into a series of ioctls which could be made = more secure. >=20 > Thank you for your feedback Warner. >=20 > Can't all SMART commands be easily identified among the others ? (when = a command arrives, does kernel sees it is SMART flagged ?) > Perhaps you assume some SMART commands may be dangerous for the disks' = data itself ? >=20 > Thank you again, >=20 Sure, there are a finite number of SMART commands, even when you = consider variations for SAS and SATL. The commands aren=E2=80=99t = explicitly flagged to the kernel, but they can be parsed. You could = even move the SMART logic directly into the kernel. However, issuing = the commands is often disruptive to the system; for SATA, it=E2=80=99s a = non-queueing command, so the system has to drain and serialize I/O while = it=E2=80=99s active. This can be crudely used as a DOS attack. There = are also SMART commands to do long-running diagnostics, that while = they=E2=80=99re not destructive, they can still be disruptive. Also, = SMART statistics can be used to gain insight into the operation of the = system, making it easier to predict I/O patterns and employ other = side-channel attacks. The point of securelevel=3D2 is to prevent access = to disk devices that can result in system disruption, so I=E2=80=99m = adverse to making an exception that=E2=80=99s directly counter to that = point. Scott