From owner-freebsd-fs@freebsd.org Fri Feb 23 21:37:18 2018 Return-Path: Delivered-To: freebsd-fs@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 62D3DF224A5; Fri, 23 Feb 2018 21:37:18 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1B837A284; Fri, 23 Feb 2018 21:37:17 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id 191so6985059wmm.4; Fri, 23 Feb 2018 13:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=cnWj3Q4nHiIKkKAJ7SJU1rpC6L2eEmD5cnWANpg44MI=; b=HXPrXKslYF3N0dcR9usaeihl5st6ieTX8peq6fDUzZF1+Gb1dPYENSXBKHOiedgtjm 55dJmxOHIV5IvyPm4gnJj2EjBMllQ5q8UN67EFneUKetvBRLMPt3HTaiFxkfMTPVKLs8 RRreiV7UtXjZFxFmBlNMqIrFPtUze5L/xNfbLHKn2+YJsTfS8AqSZfgV+qqyAlZL6cLO dnzWJAY4yFnVZhlFDEO9KWSK1ue5yYwAn+lgR2z40Dk6+8yOLMIVKwI6T9TF3kAW7EFQ ixdZIwICUkqSLkjITRNG9QWhipxVU47iAg5ilMG1DMW4dA7vXpo4+9zuVhX0XAZm7D6i wvQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=cnWj3Q4nHiIKkKAJ7SJU1rpC6L2eEmD5cnWANpg44MI=; b=ui+uohcYsBX3XVaE+aKafDP1s+yViiiOKspgAog1TlTOcCllH5+a+fcD75gEnzwDpN a1e2kXh7QvxjgFDIa9Tzj/7NX+pkk7JMBuwjY5qyF7A3xwWYOS4zdvjI+rm1+FPrkE4f R4E6m3r1l5/akU/XuZR0ut47rzygkzeX7gLgcNVjC/k7EWpSLCEa0Ac8hSdpm3qJnbGm fCRp82ahSgrJBJs1GveEtL7faDDvWr4rwSGVbs9U2slVMG5C173mrCAK9lM2ET9d8EP4 N+EqzfXfjT55sbcnN4wGybQ4G4vR4Kc3pu3jOWVlZoSFFTODjTdxWuZrRh5WQJlKBsXC vlQA== X-Gm-Message-State: APf1xPBQxMJ5ksQ0jTYxm8Ii8q9w67T5E4fWPDHHXSvvA3usq7me7uqT IrNWMKlxiKpJVDxGmy39LrlBo7ph X-Google-Smtp-Source: AG47ELtW6FXGKeNvDimoz9uN2CiMRTQmQmb2wEzioG8l9ifxabaSPC41GXsBK5U0U0oMOYpHIayLzg== X-Received: by 10.28.144.193 with SMTP id s184mr2955670wmd.68.1519421836499; Fri, 23 Feb 2018 13:37:16 -0800 (PST) Received: from bens-mac-1.home (LFbn-NIC-1-211-113.w2-15.abo.wanadoo.fr. [2.15.58.113]) by smtp.gmail.com with ESMTPSA id u22sm3735011wrf.86.2018.02.23.13.37.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Feb 2018 13:37:15 -0800 (PST) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: smartmontools and kern.securelevel From: Ben RUBSON In-Reply-To: Date: Fri, 23 Feb 2018 22:37:19 +0100 Content-Transfer-Encoding: 8bit Message-Id: References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> To: Freebsd fs , FreeBSD-scsi X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 21:37:18 -0000 >> On 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 ? >> >> Thank you again, > On 23 Feb 2018, Scott Long wrote: > Sure, there are a finite number of SMART commands, even when you consider > variations for SAS and SATL. The commands aren’t 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’s a non-queueing command, so the > system has to drain and serialize I/O while it’s active. This can be > crudely used as a DOS attack. There are also SMART commands to do > long-running diagnostics, that while they’re 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=2 is to prevent access to disk devices that can result in > system disruption, so I’m adverse to making an exception that’s directly > counter to that point. Thank you Scott. securelevel=2 really makes sense, as (IMO) SMART error reports / statistics and diagnostics. Hard to combine both actually. Perhaps a solution could be the SMART logic into the kernel, with the ability to disable it (compilation option ?). On 23 Feb 2018, Douglas Gilbert wrote: > 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). Thank you Douglas, yes you're right, SAS shared JBODs would do the trick. Mine are SAS, but unfortunately local / not shared. Theses disks are parts of ZFS pools. Instead of running zpool scrubs each 2 weeks and SMART long self tests the other 2 weeks, I could run weekly zpool scrubs. But I think I will loose the opportunity to be notified by smartmontools about a pre-dying disk, in addition sectors not yet used by ZFS would not be tested. Thank you again, Ben