From owner-freebsd-fs@freebsd.org Fri Feb 23 17:16:30 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 4DEDAF07E6B for ; Fri, 23 Feb 2018 17:16:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 D24556B64C for ; Fri, 23 Feb 2018 17:16:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id q24so3215693ioh.8 for ; Fri, 23 Feb 2018 09:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rpdYpTY1jFo5DHO02OWKA4yGvynOXUqyHj6hH4g4zQA=; b=Ubn/0Q9cHimh3A4Xwy/xLkmSHuaQ/cB2IwPsL3UsT0UjIcpj5tCh8tv1B0VRdx3amp GP2i/PuyHQ/IeZb8lfXbFpdEMBvF0jYn1GBZxwdBce5TgTHulkg8cPVUh66xPzSi04c4 SN7MyBz5y1d9bJ/s9wPNLoWCGtH7JnaXzVb1RVmyt/pjpKTCu2OBe5D/r54ncLWnR1sf eYEGNGB23nNlvQVTSCoPt8f40f1qMcpjLCEGBBZtFC34Zgj/XVcxhgIevyJ1PGtW0tkb 0vSgT2zEVTSRkAjY3MA2ZHtOS/Ikhq4NAYnfp9y8avytLsoWCYci0VPAeW+KXOt0fjKj 2XRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rpdYpTY1jFo5DHO02OWKA4yGvynOXUqyHj6hH4g4zQA=; b=cLao6VdQc+kX9kkvRmVudoxUVZmjs8USerXRzsD0c+wvdInXaN2oHHwLJVkTmFRlve HFwAlZCfD+HD5zk1qWBLAK8Uq1oCEE+wJ0hWEOcoG53xe+NL+LT2fMh6i2zeJyypRyFx /p/mOAdyvYTEtDsA0qHn/OL6tMYPsJjUtubJMKq84VtiVOaqdOszoAc56kkAez6w3pvf 21ZeG6efu+FySuTLnLi+yNzwNQoiYBHXQt8NTh11CwKSh5GBT1N/AVkGb7PVyXqC9o8O mv7a29eAn8bsEyAXwk1+eowon8FWGDtBaGl0lJs1APz5xSkGvlLqc8+7WwrekhC+HQ8h hOSg== X-Gm-Message-State: APf1xPBYoUgKCLc82opHt2QFHFpvh+8BU3LYty+Y0FgPp6fmkn9nl2ec n8HFLoxyFMpaTsDtOGSf38nBHmzWIWCBvd9+UwECvA== X-Google-Smtp-Source: AG47ELsw0lk8CapVXrasDwUkuR9DjeCOKbXqPlIesvX6sCs0qmXfAIEncwNFn5gu4UQrLwi1QgCrimpSwCNonbaK3B8= X-Received: by 10.107.175.77 with SMTP id y74mr2626545ioe.37.1519406189071; Fri, 23 Feb 2018 09:16:29 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Fri, 23 Feb 2018 09:16:28 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> From: Warner Losh Date: Fri, 23 Feb 2018 10:16:28 -0700 X-Google-Sender-Auth: pQc0FQdRfjBgXJ-PalkIU7AsvgI Message-ID: Subject: Re: smartmontools and kern.securelevel To: Ben RUBSON Cc: Freebsd fs , FreeBSD-scsi Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 17:16:30 -0000 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