Hi all, To reduce the risk of the online fsck service suffering some sort of catastrophic breach that results in attackers reconfiguring the running system, I embarked on a security audit of the systemd service files. The result should be that all elements of the background service (individual scrub jobs, the scrub_all initiator, and the failure reporting) run with as few privileges and within as strong of a sandbox as possible. Granted, this does nothing about the potential for the /kernel/ screwing up, but at least we could prevent obvious container escapes. If you're going to start using this code, I strongly recommend pulling from my git trees, which are linked below. This has been running on the djcloud for months with no problems. Enjoy! Comments and questions are, as always, welcome. --D xfsprogs git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=scrub-service-security --- Commits in this patchset: * xfs_scrub: allow auxiliary pathnames for sandboxing * xfs_scrub.service: reduce background CPU usage to less than one core if possible * xfs_scrub: use dynamic users when running as a systemd service * xfs_scrub: tighten up the security on the background systemd service * xfs_scrub_fail: tighten up the security on the background systemd service * xfs_scrub_all: tighten up the security on the background systemd service --- man/man8/xfs_scrub.8 | 9 +++- scrub/Makefile | 7 ++- scrub/phase1.c | 4 +- scrub/system-xfs_scrub.slice | 30 ++++++++++++ scrub/vfs.c | 2 - scrub/xfs_scrub.c | 11 +++- scrub/xfs_scrub.h | 5 ++ scrub/xfs_scrub@xxxxxxxxxxx | 97 ++++++++++++++++++++++++++++++++++---- scrub/xfs_scrub_all.service.in | 66 ++++++++++++++++++++++++++ scrub/xfs_scrub_fail@xxxxxxxxxxx | 59 +++++++++++++++++++++++ 10 files changed, 270 insertions(+), 20 deletions(-) create mode 100644 scrub/system-xfs_scrub.slice
