Bug 517575 - Changes for lowering capabilities project
Changes for lowering capabilities project
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: filesystem (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 519823
  Show dependency treegraph
 
Reported: 2009-08-14 14:53 EDT by Steve Grubb
Modified: 2016-06-21 09:43 EDT (History)
6 users (show)

See Also:
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:


Attachments (Terms of Use)
Patch changing file permissions (1000 bytes, patch)
2009-08-14 14:53 EDT, Steve Grubb
no flags Details | Diff

  None (edit)
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?
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)?
Comment 5 Colin Walters 2016-06-20 14:24:05 EDT
https://github.com/projectatomic/rpm-ostree/pull/335
Comment 6 Ondrej Vasik 2016-06-21 03:20:18 EDT
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...
Comment 7 Ondrej Vasik 2016-06-21 03:20:53 EDT
s/hard/easy/
Comment 8 Colin Walters 2016-06-21 08:46:59 EDT
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.
Comment 9 Steve Grubb 2016-06-21 08:49:21 EDT
Hits what? I don't see what the problem is that needs working around.
Comment 10 Michael Shigorin 2016-06-21 09:03:29 EDT
(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.
Comment 11 Steve Grubb 2016-06-21 09:15:49 EDT
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.
Comment 12 Colin Walters 2016-06-21 09:26:44 EDT
(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.
Comment 13 Steve Grubb 2016-06-21 09:43:51 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.