Harden systemd service

[topimiettinen]

Signed-off-by: Topi Miettinen toiwoton@gmail.com

[samm-git]

This should conflict with many non-sd devices, e.g. usb, scsi, raid, etc. Not something i would like to add by default.

[topimiettinen]

I could add all remaining block devices:

DeviceAllow=block-blkext r
DeviceAllow=block-device-mapper r
DeviceAllow=block-md r
DeviceAllow=block-mdp r
DeviceAllow=block-sr r

I think USB and SCSI are block-sd.

[samm-git]

See above. May be we can add it commented out, as an example.

[samm-git]

This would disallow smartd hooks to send an emails or to use any hooks with TCP interaction

[topimiettinen]

Then also IPAddressDeny=any won't be OK.

[samm-git]

Same as above - not sure if it would not cause any issues with existing device support.

[samm-git]

Thank you for PR. Not sure if we can accept it as-is. Few notes

1. Smartmontools is working with a very different hardware which we are not able to test at every release. Such enforcement will most likely cause regressions in many cases with a very limited benefits.
2. I am also not sure if OS bugs in combination with smartmontools low-lever hardware usage would not cause even more regressions.

What i can probably recommend is to document this settings on our wiki (i can help to create a page for that) and work with distribution vendors to secure their copies of the units if needed. I would like to keep our unit as simple as possible.

[samm-git]

it would not allow to send any mails or run any externals

[topimiettinen]

Thanks for the quick review. How about commenting out the controversial lines with explanatory notes? Then a local admin could make a note of them and try to enable them.

[samm-git]

I will think about this approach and will ask other contributors

[samm-git]

Follow up:

I am not convinced that there is any benefits of including this hardening to unit, commented or not commented.

1. As i mentioned above at least some of the settings would conflict with a documented smartd functionality. E.g. mail sending, external hooks, some hardware, etc.
2. Smartmontools is not acting as a network daemon and IMHO is a very unlikely to be target of any attack. Only thing you can potentially protect with such hardending is a smartmontools code bugs. However, only real issues i saw if smartmontools would work with some buggy hardware or if there are some code issues (in smartmontools, kernel or both) which causing storage device to fail, misfunction, etc. Any hardening would not protect you from such kind of problems as typically it is related to the primary functions.
3. Moreover, by getting information from RAID controller we are typically using same character device (and some ioctl-s) which is used by controller management tool. So theoretically smartmontools is capable to destroy raid or do any other things which management tool can do. Again, this hardening would not allow any protection from such problem.

So if you want that to get accepted in some form - please modify it to make sure that none of the Linux smartd functionality is affected and add some comments about every new statement in the patch, inline or as PR comment.

[samm-git]

Tagging @chrfranke to get another review :)

[chrfranke]

I agree with @samm-git. Such complex settings may affect various external scripts in ways which are difficult to predict. The attack surface of smartd itself is small as it does not use network connections or IPC. The only exception is a AF_UNIX socket (/var/run/systemd/notify) if Type=notify is used.

Does the current PR allow mknod() calls? If not, this may break usage of -d aacraid, -d megaraid (and legacy -d 3ware) device types.

Please note that there is a old smartd option -C (--capabilities), see ticket 45. It possibly has the same effect as:

CapabilityBoundingSet=CAP_SYS_ADMIN CAP_SYS_RAWIO CAP_MKNOD

[samm-git]

I am closing this PR as potentially dangerous and without clear benefits for the users. Also our systemd service unit file is provided for the reference only and expected to be changed by the OS maintainers, so better to keep it as simple as possible.

[topimiettinen]

I understand your decision. I don't think distros will see things differently, probably the expectation is to keep mail sending features etc. working. This level of hardening only works without those features.

Please note that while smartd might not be target to remote exploits, it may still become a stepping stone to gain more privileges (it's actually a juicy target with root equivalent capabilities) once the attacker gets in. I'd also recommend you to try to seeing hardening as positive thing and not dangerous.

[samm-git]

@topimiettinen thanks for understanding. I seeing it as a positive but dangerous thing :)