smartmontools and kern.securelevel

[Ben RUBSON]

>> 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:
>>>
>>>> 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