Created attachment 357496 [details]
Patch changing file permissions
Description of problem:
As part of the lowering capabilities project, we should tighten permissions on several directories. I will attach a patch against the spec file that does this.
Using attached patch will cause duplicities in filelist, however, that's easy to fix. Built with directory permissions from patch as filesystem-2.4.30-1.fc12, closing RAWHIDE.
JFYI, you've essentially blocked formation of chroots without "real" euid==0 (e.g., ALT Linux' privsep hasher employs fakeroot and rpm2cpio to populate initial chroot then rpm to install further packages).
It's also somewhat surprising to see a change like this lacking a link to any rationale/discussion (albeit it still looks like a bit of publicity on an indoors discussion, thanks).
Hope those responsible for bug #519823 did comprehend some advice from Solar Designer (http://www.openwall.com/lists/oss-security/2010/11/08/3)...
(In reply to Michael Shigorin from comment #2)
> JFYI, you've essentially blocked formation of chroots without "real" euid==0
You mean CAP_DAC_OVERRIDE.
> (e.g., ALT Linux' privsep hasher employs fakeroot and rpm2cpio to populate
It's pretty trivial though to just chmod -R u+w rootpath/ after extraction, which is how I worked around this.
Anyways, this was a well-intentioned idea, but in reality it won't work without significant further work because a process with uid 0 but not CAP_DAC_OVERRIDE is still perfectly capable of rewriting e.g. /usr/bin/bash which still has u+w, or /root/.bashrc for that matter. The answer to this sort of thing is SELinux. Any objections to a patch to revert back to mode 755 for directories?
Isn't it funny given https://fedorahosted.org/fpc/ticket/467 and the fact that non-privileged chroot generation has been solved at least a decade ago (with fakeroot and helpers like hasher-priv but anyways)?
Just saw the comments (comments in closed bzs without needinfo are hard to miss when I get hundreds emails from bz every day).
Colin, if you have some objections against this change, feel free to reopen and set needinfo on Steve Grubb. I agree this change is not perfect and doesn't help too much with the security of the system... but I'm not going to revert the permissions back to 755 without further discussion with Steve...
It's not a big deal, the code to effectively revert it rpm-ostree is small and shouldn't be hard to carry over time.
I just wanted to cross-link the bugs so that anyone else who hit this can see the change we did in rpm-ostree.
Hits what? I don't see what the problem is that needs working around.
(In reply to Colin Walters from comment #8)
> It's not a big deal, the code to effectively revert it [in] rpm-ostree
It's about kludges that are needed in any tool of the class to cope with this.
(In reply to Steve Grubb from comment #9)
> Hits what? I don't see what the problem is that needs working around.
Unprivileged code (e.g. anything using fakeroot) that *does* get its access checks unlike euid==0 gets EACCESS, obviously. And real root won't be stopped by this kind of "restrictions" unless I'm missing something equally obvious in the problem you intended to solve in the first place.
The changes takes away write permissions for root so that you also need DAC_OVERRIDE in order to write. We then dropped capabilities on things that needed to be root but are network facing or setuid.
I've never used fakeroot for anything. What problem does it have? If its trying to write to system directories, it should have a problem.
(In reply to Steve Grubb from comment #11)
> The changes takes away write permissions for root so that you also need
> DAC_OVERRIDE in order to write. We then dropped capabilities on things that
> needed to be root but are network facing or setuid.
See https://bugzilla.redhat.com/show_bug.cgi?id=517575#c3 for example.
> I've never used fakeroot for anything. What problem does it have? If its
> trying to write to system directories, it should have a problem.
FWIW one thing I'm fixing with rpm-ostree is that combined with https://github.com/projectatomic/bubblewrap it will be able to run unprivileged, with the primary use case for this being build roots. Like Yocto which uses https://www.yoctoproject.org/tools-resources/projects/pseudo except using container features instead of LD_PRELOAD>
Right now everyone submitting RPMs to a build system that doesn't operate this way (without using virtualization as OBS and COPR do), has easy access to CAP_SYS_ADMIN on the build server.
Again, I don't know the exact problem you are facing, but if the build system is running as a normal user, it should be using the umask of the user to create directories that it writes to and then apply permissions (owner/group/mode) only during install of the resulting package on the user's system. The permissions of the prepackaged software do not have to be a faithful representation prior to packaging.
*** Bug 1416600 has been marked as a duplicate of this bug. ***
*** Bug 1588016 has been marked as a duplicate of this bug. ***