smartmontools and kern.securelevel
ben.rubson at gmail.com
Fri Feb 23 21:37:18 UTC 2018
>> On Feb 23, 2018, at 9:46 AM, Ben RUBSON <ben.rubson at gmail.com> wrote:
>> On 23 Feb 2018, Warner Losh wrote:
>>> On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON <ben.rubson at gmail.com> wrote:
>>>> 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
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
Thank you again,
More information about the freebsd-fs