| Message ID | 170502573653.996574.9591002351083368679.stg-ugh@frogsfrogsfrogs (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL,1/6] xfsprogs: various bug fixes for 6.6 | expand |
On Thu, Jan 11, 2024 at 06:17:43PM -0800, Darrick J. Wong wrote: > Hi Carlos, > > Please pull this branch with changes for xfsprogs for 6.6-rc1. > > As usual, I did a test-merge with the main upstream branch as of a few > minutes ago, and didn't see any conflicts. Please let me know if you > encounter any problems. > > The following changes since commit 1c95c17c8857223d05e8c4516af42c6d41ae579a: > > xfs_scrub_all: fix termination signal handling (2024-01-11 18:08:47 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git tags/scrub-service-security-6.6_2024-01-11 > > for you to fetch changes up to 13995601c86574e2f65d93055ac7a624fbde4443: > > xfs_scrub_all: tighten up the security on the background systemd service (2024-01-11 18:08:47 -0800) As we spoke, this branch contain patches without Reviewed-by tags, I won't be pulling this branch by now. Cheers, Carlos > > ---------------------------------------------------------------- > xfs_scrub: tighten security of systemd services [v28.3 6/6] > > 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. > > Signed-off-by: Darrick J. Wong <djwong@kernel.org> > > ---------------------------------------------------------------- > Darrick J. Wong (6): > xfs_scrub: allow auxiliary pathnames for sandboxing > xfs_scrub.service: reduce CPU usage to 60% when 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@.service.in | 97 +++++++++++++++++++++++++++++++++++----- > scrub/xfs_scrub_all.service.in | 66 +++++++++++++++++++++++++++ > scrub/xfs_scrub_fail@.service.in | 59 ++++++++++++++++++++++++ > 10 files changed, 270 insertions(+), 20 deletions(-) > create mode 100644 scrub/system-xfs_scrub.slice >
Hi Carlos, Please pull this branch with changes for xfsprogs for 6.6-rc1. As usual, I did a test-merge with the main upstream branch as of a few minutes ago, and didn't see any conflicts. Please let me know if you encounter any problems. The following changes since commit 1c95c17c8857223d05e8c4516af42c6d41ae579a: xfs_scrub_all: fix termination signal handling (2024-01-11 18:08:47 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git tags/scrub-service-security-6.6_2024-01-11 for you to fetch changes up to 13995601c86574e2f65d93055ac7a624fbde4443: xfs_scrub_all: tighten up the security on the background systemd service (2024-01-11 18:08:47 -0800) ---------------------------------------------------------------- xfs_scrub: tighten security of systemd services [v28.3 6/6] 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. Signed-off-by: Darrick J. Wong <djwong@kernel.org> ---------------------------------------------------------------- Darrick J. Wong (6): xfs_scrub: allow auxiliary pathnames for sandboxing xfs_scrub.service: reduce CPU usage to 60% when 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@.service.in | 97 +++++++++++++++++++++++++++++++++++----- scrub/xfs_scrub_all.service.in | 66 +++++++++++++++++++++++++++ scrub/xfs_scrub_fail@.service.in | 59 ++++++++++++++++++++++++ 10 files changed, 270 insertions(+), 20 deletions(-) create mode 100644 scrub/system-xfs_scrub.slice