smartmontools and kern.securelevel

[Scott Long]

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

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.

Scott