Date: Fri, 23 Feb 2018 10:20:12 -0700 From: Scott Long <scottl@samsco.org> To: Ben RUBSON <ben.rubson@gmail.com> Cc: Warner Losh <imp@bsdimp.com>, Freebsd fs <freebsd-fs@freebsd.org>, FreeBSD-scsi <freebsd-scsi@freebsd.org> Subject: Re: smartmontools and kern.securelevel Message-ID: <EA852D1E-6F15-4D3C-9DFB-D5D6F2291E5F@samsco.org> In-Reply-To: <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <CANCZdfo4PZv7ueCZUZ_bnPu26mL12HAUzfoszhXeDkrTShV6zA@mail.gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Feb 23, 2018, at 9:46 AM, Ben RUBSON <ben.rubson@gmail.com> wrote: >=20 > On 23 Feb 2018, Warner Losh wrote: >=20 >> On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON <ben.rubson@gmail.com> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EA852D1E-6F15-4D3C-9DFB-D5D6F2291E5F>