Date: Fri, 23 Feb 2018 12:49:16 -0500 From: Douglas Gilbert <dgilbert@interlog.com> To: freebsd-scsi@freebsd.org Subject: Re: smartmontools and kern.securelevel Message-ID: <93284cad-7a4f-10ec-4a5d-e8a820c0a5fd@interlog.com> In-Reply-To: <CANCZdfqiK2Hz20Sso0_uA8FAD4=2z0FY=iPLdK=dX5p5OPq_3Q@mail.gmail.com> References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <CANCZdfo4PZv7ueCZUZ_bnPu26mL12HAUzfoszhXeDkrTShV6zA@mail.gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> <CANCZdfqiK2Hz20Sso0_uA8FAD4=2z0FY=iPLdK=dX5p5OPq_3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-02-23 12:16 PM, Warner Losh wrote: > On Fri, Feb 23, 2018 at 9:46 AM, Ben RUBSON <ben.rubson@gmail.com> wrote: > >> On 23 Feb 2018, Warner Losh wrote: >> >> On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON <ben.rubson@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93284cad-7a4f-10ec-4a5d-e8a820c0a5fd>