Bug 517575

Summary: Changes for lowering capabilities project
Product: [Fedora] Fedora Reporter: Steve Grubb <sgrubb>
Component: filesystemAssignee: Ondrej Vasik <ovasik>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: kvolny, ldv, ovasik, rjones, shigorin, walters
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-08-17 09:12:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 519823    
Description Flags
Patch changing file permissions none

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


> (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?
Comment 4 Michael Shigorin 2014-11-14 15:39:06 EST
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)?