GNOME Bugzilla – Bug 722984
Remove setuid bit from undeployed binaries
Last modified: 2018-08-17 19:00:05 UTC
If the system is updated for security reasons, the OSTree model can leave old, still potentially vulnerable binaries on the system. Trying to make the repository a nosuid bind mount isn't going to work, because that would cause link() to fail with EXDEV, which breaks the entire OSTree model. One potential solution: Keep the setuid-bitness noted in a separate place (e.g. a simple file .setuidstate, or perhaps a repository-global list of objects which are setuid). Only apply it for deployed binaries. But this still doesn't help for the quite common case where you do an update, and the old deployment is still on disk. I think we need a dynamic solution where the setuid bit is applied on *bootup* to make this work. Ugly =/ But doable.
One alternative is to use the xattr approach that bare-user is now using. I.e. store the file as is, sans the setuid bit, and then store the real mode in an xattr. The main downside is that you can't use hardlinking to check out such a file, but i doubt this is a real problem, as very few files should be setuid.
One problem we'll have with any solution here is format versioning. Basically if I upgrade to a tree which has a version of ostree which has some on-disk change like this, then I roll back, the *old* version of ostree will think the new version is corrupted. We'll need some scheme like "migrate local repository when all trees have an upgraded version" or so.
I was thinking recently that a variation on the "retain setuid state outside of the tree" is to actually copy them into e.g. /run/ostree/setuid/ and generate symlinks in the tree.
I think you could bind-remount /sysroot/ostree as nosuid Something like: mount -B -o nosuid /sysroot/ostree /sysroot/ostree mount -B -o remount,nosuid /sysroot/ostree /sysroot/ostree (As usual it has to be done twice: https://bugzilla.kernel.org/show_bug.cgi?id=24912; in theory this was supposed to have been worked around in util-linux's mount in 2.27, but in fact that only handled remounting as ro, and not the similar nosuid/noexec bits) Or you could remount /sysroot as nosuid, but that would mean /home couldn't have setuid programs (probably a good thing, but it's more intrusive): mount -B -o remount,nosuid /sysroot /sysroot Either way, though, I believe all ostree operations would continue to work, since ostree/repo and ostree/deploy will be in the same bind mount under this approach. And the result is that only executables from the booted system will be able to setuid.
That's an interesting idea, worth testing to see if it works and if it breaks anything else.
OSTree has moved to Github a while ago. Furthermore, GNOME Bugzilla will be shut down and replaced by gitlab.gnome.org. If the problem reported in this Bugzilla ticket is still valid, please report it to https://github.com/ostreedev/ostree/issues instead. Thank you! Closing this report as WONTFIX as part of Bugzilla Housekeeping.