Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Changes for lowering capabilities project|
|Product:||[Fedora] Fedora||Reporter:||Steve Grubb <sgrubb>|
|Component:||filesystem||Assignee:||Ondrej Vasik <ovasik>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||kvolny, ldv, ovasik, rjones, shigorin, walters|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-08-17 09:12:46 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Steve Grubb 2009-08-14 14:53:14 EDT
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.
Comment 1 Ondrej Vasik 2009-08-17 09:12:46 EDT
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.
Comment 2 Michael Shigorin 2011-12-26 15:58:54 EST
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)...
Comment 3 Colin Walters 2013-05-31 14:25:01 EDT
(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?