Bug 517575 - Changes for lowering capabilities project
Summary: Changes for lowering capabilities project
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: filesystem
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1416600 1588016 (view as bug list)
Depends On:
Blocks: 519823
TreeView+ depends on / blocked
 
Reported: 2009-08-14 18:53 UTC by Steve Grubb
Modified: 2021-06-29 12:03 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-17 13:12:46 UTC
Type: ---
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1416600 0 unspecified CLOSED A few folders in /usr are not owner-writable 2021-02-22 00:41:40 UTC

Internal Links: 1416600 2121162

Description Steve Grubb 2009-08-14 18:53:14 UTC
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 13:12:46 UTC
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 20:58:54 UTC
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 18:25:01 UTC
(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 20:39:06 UTC
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 18:24:05 UTC
https://github.com/projectatomic/rpm-ostree/pull/335

Comment 6 Ondrej Vasik 2016-06-21 07:20:18 UTC
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 07:20:53 UTC
s/hard/easy/

Comment 8 Colin Walters 2016-06-21 12:46:59 UTC
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 12:49:21 UTC
Hits what? I don't see what the problem is that needs working around.

Comment 10 Michael Shigorin 2016-06-21 13:03:29 UTC
(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 13:15:49 UTC
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 13:26:44 UTC
(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 13:43:51 UTC
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.

Comment 14 Colin Walters 2017-01-27 22:45:37 UTC
*** Bug 1416600 has been marked as a duplicate of this bug. ***

Comment 15 Jaroslav Škarvada 2018-06-06 14:13:25 UTC
*** Bug 1588016 has been marked as a duplicate of this bug. ***


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