{"action":"closed","issue":{"url":"https://api.github.com/repos/systemd/systemd/issues/9857","repository_url":"https://api.github.com/repos/systemd/systemd","labels_url":"https://api.github.com/repos/systemd/systemd/issues/9857/labels{/name}","comments_url":"https://api.github.com/repos/systemd/systemd/issues/9857/comments","events_url":"https://api.github.com/repos/systemd/systemd/issues/9857/events","html_url":"https://github.com/systemd/systemd/issues/9857","id":349740828,"node_id":"MDU6SXNzdWUzNDk3NDA4Mjg=","number":9857,"title":"Hole in `ProtectSystem=` etc. due to mount propagation","user":{"login":"sourcejedi","id":14057,"node_id":"MDQ6VXNlcjE0MDU3","avatar_url":"https://avatars0.githubusercontent.com/u/14057?v=4","gravatar_id":"","url":"https://api.github.com/users/sourcejedi","html_url":"https://github.com/sourcejedi","followers_url":"https://api.github.com/users/sourcejedi/followers","following_url":"https://api.github.com/users/sourcejedi/following{/other_user}","gists_url":"https://api.github.com/users/sourcejedi/gists{/gist_id}","starred_url":"https://api.github.com/users/sourcejedi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sourcejedi/subscriptions","organizations_url":"https://api.github.com/users/sourcejedi/orgs","repos_url":"https://api.github.com/users/sourcejedi/repos","events_url":"https://api.github.com/users/sourcejedi/events{/privacy}","received_events_url":"https://api.github.com/users/sourcejedi/received_events","type":"User","site_admin":false},"labels":[{"id":219550649,"node_id":"MDU6TGFiZWwyMTk1NTA2NDk=","url":"https://api.github.com/repos/systemd/systemd/labels/documentation%20%F0%9F%93%96","name":"documentation 📖","color":"bfe5bf","default":false},{"id":268297924,"node_id":"MDU6TGFiZWwyNjgyOTc5MjQ=","url":"https://api.github.com/repos/systemd/systemd/labels/has-pr%20%E2%9C%A8","name":"has-pr ✨","color":"009800","default":false},{"id":221925707,"node_id":"MDU6TGFiZWwyMjE5MjU3MDc=","url":"https://api.github.com/repos/systemd/systemd/labels/pid1","name":"pid1","color":"c7def8","default":false}],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/systemd/systemd/milestones/17","html_url":"https://github.com/systemd/systemd/milestone/17","labels_url":"https://api.github.com/repos/systemd/systemd/milestones/17/labels","id":3416475,"node_id":"MDk6TWlsZXN0b25lMzQxNjQ3NQ==","number":17,"title":"v240","description":"","creator":{"login":"poettering","id":2130732,"node_id":"MDQ6VXNlcjIxMzA3MzI=","avatar_url":"https://avatars1.githubusercontent.com/u/2130732?v=4","gravatar_id":"","url":"https://api.github.com/users/poettering","html_url":"https://github.com/poettering","followers_url":"https://api.github.com/users/poettering/followers","following_url":"https://api.github.com/users/poettering/following{/other_user}","gists_url":"https://api.github.com/users/poettering/gists{/gist_id}","starred_url":"https://api.github.com/users/poettering/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/poettering/subscriptions","organizations_url":"https://api.github.com/users/poettering/orgs","repos_url":"https://api.github.com/users/poettering/repos","events_url":"https://api.github.com/users/poettering/events{/privacy}","received_events_url":"https://api.github.com/users/poettering/received_events","type":"User","site_admin":false},"open_issues":18,"closed_issues":65,"state":"open","created_at":"2018-06-11T17:19:42Z","updated_at":"2018-10-30T22:55:57Z","due_on":null,"closed_at":null},"comments":10,"created_at":"2018-08-11T15:09:40Z","updated_at":"2018-10-30T22:55:57Z","closed_at":"2018-10-30T22:55:57Z","author_association":"CONTRIBUTOR","body":"**systemd version the issue has been seen with**\r\nv238\r\n\r\n<!-- **NOTE:** Do not submit bug reports about anything but the two most recently released systemd versions upstream! -->\r\n<!-- For older version please use distribution trackers (see https://github.com/systemd/systemd/blob/master/.github/CONTRIBUTING.md#filing-issues). -->\r\n\r\n**Used distribution**\r\nFedora Workstation 28\r\n\r\n**Expected behaviour you didn't see**\r\n`ProtectSystem=strict` \"ensures that any modification of the ... local mounts is prohibited for the service\" - `man systemd.exec`\r\n\r\n**Unexpected behaviour you saw**\r\nLocal mounts can be modified, if the mount is created after the service is started.\r\n\r\n(And I noticed that `ProtectSystem=strict` or `ProtectHome=read-only` do not imply `After=home.mount`. So this hole could be triggered by the normal boot process).\r\n\r\n**Steps to reproduce the problem**\r\n\r\n1. `systemctl cat systemd-resolved | grep ProtectSystem=strict`\r\n2. `systemctl start systemd-resolved`\r\n3. `eval \"$(systemctl show -p MainPID systemd-resolved)\"`\r\n4. `nsenter --mount -t $MainPID touch /mnt/a`\r\n5. `mount tmpfs -t tmpfs /mnt`\r\n6. `nsenter --mount -t $MainPID touch /mnt/a`\r\n\r\nObserved behaviour on v238:\r\n\r\n* step 4 fails with \"Read-only file system\"\r\n* step 6 succeeds.\r\n\r\n**Fixing this problem**\r\n\r\nI would say the \"hole\" in ProtectSystem= is unfixable.  See next section.\r\n\r\nI think the bug is in the documentation for `ProtectSystem=`, suggesting it does something that it cannot.  Currently the documentation mentions the \"hole\" only in `ReadOnlyPaths=`.\r\n\r\nAt the very end of `ProtectSystem=`, it mentions that \"The same restrictions regarding mount propagation and privileges apply as for `ReadOnlyPaths=`\".  But, where `ReadOnlyPaths=` does mention \"restricting access with these options does not extend to submounts of a directory that are created later on\", the word \"mount propagation\" is not mentioned.  And `ReadOnlyPaths=` mentions another restriction in terms of \"mount propagation\", so the \"hole\" could even be overlooked.\r\n\r\nIt might be clearer to say \"This setting cannot ensure protection in all cases. In general it has the same limitations as ReadOnlyPaths=, see below.\"\r\n\r\nIMO: it is easy for users to expect the \"restriction\" regarding privileges, that privileged services could be able to remount the directory read-write.  But mount propagation is not as obvious to users.  Mount propagation is not as widely understood, and the \"hole\" it causes is more unusual.\r\n\r\nIt seems non-obvious that systemd would provide a `ProtectHome=read-only` option, that does not work when home directories are encrypted (see `pam_ecryptfs`), or stored on a network filesystem... (network filesystems are mounted after `basic.target`)\r\n\r\nMaybe the documentation for `ProtectSystem=strict` already mentions the `netfs` case, with the word \"local\" in \"ensures that any modification of the ... local mounts is prohibited\".  But it does not seem very clear.  And it seems inaccurate, because it also doesn't protect mounts made at runtime like automounts or user mounted disks, even if they are local mounts.\r\n\r\n**Why the \"hole\" cannot be fixed**\r\n\r\nWe cannot disable propagation of mount changes into the service namespace. It is needed, to allow ejecting removable media which was mounted in the main namespace.\r\n\r\nSo far, Linux only supports enabling or disabling this propagation.  We can't allow unmounts to propagate without also allowing mounts to propagate.\r\n\r\nEDIT: You can also avoid daemons seeing user mounts at all e.g. by running users as `PrivateMounts=yes`.  The problem is this breaks expected behaviour with `mount`, `sudo mount`, etc.  This might be interesting to admins who want to harden multi-user systems.  It would also make sure not to leave user mounts after logout, if `KillUserProcesses=yes` is set in logind."}}
{"actor":{"display_login":"keszybz"}}