From owner-freebsd-scsi@freebsd.org Fri Feb 23 17:49:25 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 9E81DF0BD1B for ; Fri, 23 Feb 2018 17:49:25 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6F16CDF8 for ; Fri, 23 Feb 2018 17:49:24 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 00FDD2041BB for ; Fri, 23 Feb 2018 18:49:18 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv1XlxEDivu5 for ; Fri, 23 Feb 2018 18:49:17 +0100 (CET) Received: from [10.7.0.10] (unknown [10.7.0.10]) by smtp.infotech.no (Postfix) with ESMTPA id 835A02040A6 for ; Fri, 23 Feb 2018 18:49:17 +0100 (CET) Reply-To: dgilbert@interlog.com Subject: Re: smartmontools and kern.securelevel To: freebsd-scsi@freebsd.org References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> From: Douglas Gilbert Message-ID: <93284cad-7a4f-10ec-4a5d-e8a820c0a5fd@interlog.com> Date: Fri, 23 Feb 2018 12:49:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit 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:49:25 -0000 On 2018-02-23 12:16 PM, Warner Losh wrote: > On Fri, Feb 23, 2018 at 9:46 AM, Ben RUBSON wrote: > >> On 23 Feb 2018, Warner Losh wrote: >> >> On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON wrote: >>> >>> Hi, >>>> >>>> I run smartmontools on my storage servers, to launch periodic disk tests >>>> and alert on disk errors. >>>> >>>> Unfortunately, if we set sysctl kern.securelevel >=2, 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)) >>>> >>>> Any workaround to this ? >>>> >>>> Perhaps we could think about allowing SMART commands to be written to >>>> disks when sysctl kern.securelevel >=2 ? >>>> (I assume smartmontools writes SMART commands) >>>> >>> >>> 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. >>> >> >> Thank you for your feedback Warner. >> >> 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 ? >> > > Yes. I do. They can be. > > Warner A partial solution with big storage behind a storage switch (FC, PCIe or SAS) is to run one machine *** (preferably not accessible directly from the internet) at a lower privilege level that permits it to run smartmontools and other similar utilities (such as a management utility for that storage switch). Then all other machines, especially those that provided services to (or accessible from) the internet, can run at a higher privilege level precluding smartmontools. You might want to add wireless access (e.g. WiFi and/or Bluetooth) to the "internet" as a possible attack vector. If someone told me that I was at the keyboard of an extremely safe Linux system and I had a login, then I would check if it was running my drivers: sg and scsi_debug (a SCSI command pass-through and a pseudo SCSI low level device driver). If it was then I would suggest that machine wasn't safe enough ... Basically there is no way an OS can foresee what tricks you can get up to with a pass-through. Consider a "third party copy" (SCSI EXTENDED COPY command). That can be sent to a "copy manager" which is neither the source nor destination of that copy. Security that concentrates on the copy manager is flawed. Microsoft ban this command with their Windows pass-thru. If I was a vendor with a customer wanting the offloaded copy capability and ran a Microsoft OS, then I would just replicate the functionality of EXTENDED COPY in a vendor specific command! That wouldn't be much code. Problem solved, happy customer. Doug Gilbert *** And make that a _real_ machine, not a VM :-) With a real console.