smartmontools and kern.securelevel

[Douglas Gilbert]

On 2018-02-23 12:16 PM, Warner Losh wrote:
> On Fri, 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 ?
>>
> 
> Yes. I do. They can be.
> 
> Warner

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). Then all other machines, especially those that provided
services to (or accessible from) the internet, can run at a higher privilege
level precluding smartmontools. You might want to add wireless access
(e.g. WiFi and/or Bluetooth) to the "internet" as a possible attack vector.


If someone told me that I was at the keyboard of an extremely safe Linux
system and I had a login, then I would check if it was running my drivers:
sg and scsi_debug (a SCSI command pass-through and a pseudo SCSI low level
device driver). If it was then I would suggest that machine wasn't safe
enough ...


Basically there is no way an OS can foresee what tricks you can get up to
with a pass-through. Consider a "third party copy" (SCSI EXTENDED COPY
command). That can be sent to a "copy manager" which is neither the source
nor destination of that copy. Security that concentrates on the copy
manager is flawed. Microsoft ban this command with their Windows pass-thru.
If I was a vendor with a customer wanting the offloaded copy capability
and ran a Microsoft OS, then I would just replicate the functionality of
EXTENDED COPY in a vendor specific command! That wouldn't be much code.
Problem solved, happy customer.

Doug Gilbert


*** And make that a _real_ machine, not a VM :-) With a real console.