Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Guillem Jover]

On Wed, 2020-08-05 at 00:58:27 +0200, Ansgar wrote:
> On Tue, 2020-08-04 at 23:50 +0200, Guillem Jover wrote:
> > On Tue, 2020-08-04 at 13:56:45 -0700, Russ Allbery wrote:
> > > Ansgar  writes:
> > > > 10.9 Permissions and owners currently says
> > > > > Files should be owned by root:root, and made writable only by the
> > > > > owner and universally readable (and executable, if appropriate),
> > > > > that is mode 644 or 755."
> > > > However most files shouldn't be modified as modifications will just be
> > > > lost (e.g. everything installed by the package manager that isn't
> > > > handled as a conffile).  It also gives more permissions than the minimum
> > > > needed.
> > 
> > I'm not sure why we need to protect the local sysadmin(s) from this? Also
> > root can just write to any file regardless of the permissions.
> 
> The same reason that `rm -rf /` gives an error these days? :)

That might have been a good argument if root honored those missing
write-perms, but it does not. :)

> People modify files managed by dpkg from time to time and wonder why
> these modifications suddenly disappear on upgrades.  Or some package
> might assume a file is writable and use it, then data is lost on
> upgrade.  (I'm fairy certain to remember bug reports about that for
> files shipped in /var.)

Well, I guess they'll eventually understand what's going on?

> Various files are read-only anyway (such as `/bin/bash` when a shell is
> running).

But, that's just the standard Unix behavior of ETXTBSY, where the
file has been mmap()ed so you don't want to allow writing to it,
otherwise you'd end up modifying running code, ending up in at least
crashes. You can of course still unlink or rename these files though.

> > Countless
> > times I've modified local files, for example, to fix an issue that is
> > pending upload. And while that does not require write perms if done as
> > root, both of the above would seem to counter this as a good reason
> > for this change?
> 
> You can still do that if you really want to; editors will warn users if
> they modify read-only files, even when they provide an override to
> force writing the file.

Actually, editors need explicit support for this when running as root,
and this pretty much mostly applies to text files. For example nano
has no such protection.

So, I'm still failing to see what kind of protection this gives
anyway, because it does not really protect from root itself.

> > > Maybe it
> > > would make sense for Guillem to weigh in first and indicate whether this
> > > would be a problem on the dpkg side and if he sees any concerns.  Copying
> > > debian-dpkg@lists for that.
> > 
> > Thanks! Was meaning to comment anyway. :)
> > 
> > This would break installations as non-root, as those users will not
> > have enough privs to create the objects to extract. So that alone seems
> > like a non-starter.
> 
> Why would non-root users not be able to create files with 444
> permissions instead of 644?

First, due to the missing perms in directories. If we ignored that and
only removed write perms from regular files, then that would still
fail due to the needed delayed syncing required by new filesystem
so that they can behave in a sensible way when it comes to
performance. And while, f.ex., at least Linux does support passing a
read-only fd to fsync(2), this is a non-portable assumption.

Thanks,
Guillem

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Sam Hartman]

I'm ignoring the case where capabilities are dropped in my analysis.

I've long valued that Debian does not mark file paths as readonly and
would not support this change.
I've worked on other Unix distributions that did this, and I found that
it decreased the  quality of life of the sysadmin enough that I just
enjoyed being on Debian better and that this decision was one that
contributed.

Yes, root can write to anything.
But several tools make it harder to write to things as root  if they are
without write permission.

I think the value of stability and  making it easy for the sysadmins is
more important than this change absent cases where capabilities are
dropped.

I haven't thought about the capability dropped case enough.  If that
ends up being our rationale, I could hold my nose and go off in my own
corner and grow a beard and grumble in my old age, talking about how
great things used to be back in the day.

In other cases I'm strongly opposed to this change.

--Sam


signature.asc
Description: PGP signature

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Ansgar]

On Tue, 2020-08-04 at 23:50 +0200, Guillem Jover wrote:
> On Tue, 2020-08-04 at 13:56:45 -0700, Russ Allbery wrote:
> > Ansgar  writes:
> > > 10.9 Permissions and owners currently says
> > > > Files should be owned by root:root, and made writable only by the
> > > > owner and universally readable (and executable, if appropriate),
> > > > that is mode 644 or 755."
> > > However most files shouldn't be modified as modifications will just be
> > > lost (e.g. everything installed by the package manager that isn't
> > > handled as a conffile).  It also gives more permissions than the minimum
> > > needed.
> 
> I'm not sure why we need to protect the local sysadmin(s) from this? Also
> root can just write to any file regardless of the permissions.

The same reason that `rm -rf /` gives an error these days? :)

People modify files managed by dpkg from time to time and wonder why
these modifications suddenly disappear on upgrades.  Or some package
might assume a file is writable and use it, then data is lost on
upgrade.  (I'm fairy certain to remember bug reports about that for
files shipped in /var.)

Various files are read-only anyway (such as `/bin/bash` when a shell is
running).

> Countless
> times I've modified local files, for example, to fix an issue that is
> pending upload. And while that does not require write perms if done as
> root, both of the above would seem to counter this as a good reason
> for this change?

You can still do that if you really want to; editors will warn users if
they modify read-only files, even when they provide an override to
force writing the file.

> > The basic argument makes sense to me, but this is the sort of change where
> > we'll need to figure out a transition strategy coordinated across multiple
> > packages, since this behavior is encoded in a lot of places.

Probably mostly debhelper (dh_fixperms)?

> > Maybe it
> > would make sense for Guillem to weigh in first and indicate whether this
> > would be a problem on the dpkg side and if he sees any concerns.  Copying
> > debian-dpkg@lists for that.
> 
> Thanks! Was meaning to comment anyway. :)
> 
> This would break installations as non-root, as those users will not
> have enough privs to create the objects to extract. So that alone seems
> like a non-starter.

Why would non-root users not be able to create files with 444
permissions instead of 644?

Ansgar

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Russ Allbery]

Guillem Jover  writes:
> On Tue, 2020-08-04 at 13:56:45 -0700, Russ Allbery wrote:

>> I assume this is in support of systems, containers, or jails where UID
>> 0 may not have CAP_FOWNER?

> If that's the reason, it certainly was not clear from the original
> report. :)

It seems like the context in which this change would be meaningful.

That said, in the situations where I'm dropping capabilities, I would also
generally remount file systems like /usr read-only (systemd's
ProtectSystem, for example), so I'm having some trouble generating a
scenario in which the file permission changes matter.  I think a concrete
use case would be useful for analysis.

-- 
Russ Allbery (r...@debian.org)  

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Guillem Jover]

On Tue, 2020-08-04 at 13:56:45 -0700, Russ Allbery wrote:
> Ansgar  writes:
> > 10.9 Permissions and owners currently says
> 
> > | Files should be owned by root:root, and made writable only by the
> > | owner and universally readable (and executable, if appropriate),
> > | that is mode 644 or 755."
> 
> > However most files shouldn't be modified as modifications will just be
> > lost (e.g. everything installed by the package manager that isn't
> > handled as a conffile).  It also gives more permissions than the minimum
> > needed.

I'm not sure why we need to protect the local sysadmin(s) from this? Also
root can just write to any file regardless of the permissions. Countless
times I've modified local files, for example, to fix an issue that is
pending upload. And while that does not require write perms if done as
root, both of the above would seem to counter this as a good reason
for this change?

(I could also see this being performed by one of the other "admin" roles
in the system that is not root.)

> > I think static files should not be writable instead, so every file under
> > /usr (and /bin, /sbin, /lib*; or everything dpkg installs that is not a
> > conffile) should have 444 (or 555).
> 
> I assume this is in support of systems, containers, or jails where UID 0
> may not have CAP_FOWNER?

If that's the reason, it certainly was not clear from the original
report. :)

> The basic argument makes sense to me, but this is the sort of change where
> we'll need to figure out a transition strategy coordinated across multiple
> packages, since this behavior is encoded in a lot of places.  Maybe it
> would make sense for Guillem to weigh in first and indicate whether this
> would be a problem on the dpkg side and if he sees any concerns.  Copying
> debian-dpkg@lists for that.

Thanks! Was meaning to comment anyway. :)

This would break installations as non-root, as those users will not
have enough privs to create the objects to extract. So that alone seems
like a non-starter.

Thanks,
Guillem

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Bill Allombert]

On Tue, Aug 04, 2020 at 02:15:59PM +0200, Ansgar wrote:
> Package: debian-policy
> 
> Hi,
> 
> 10.9 Permissions and owners currently says
> 
> | Files should be owned by root:root, and made writable only by the
> | owner and universally readable (and executable, if appropriate),
> | that is mode 644 or 755."
> 
> However most files shouldn't be modified as modifications will just be
> lost (e.g. everything installed by the package manager that isn't
> handled as a conffile).  It also gives more permissions than the
> minimum needed.

What about dpkg-divert ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Russ Allbery]

Ansgar  writes:

> 10.9 Permissions and owners currently says

> | Files should be owned by root:root, and made writable only by the
> | owner and universally readable (and executable, if appropriate),
> | that is mode 644 or 755."

> However most files shouldn't be modified as modifications will just be
> lost (e.g. everything installed by the package manager that isn't
> handled as a conffile).  It also gives more permissions than the minimum
> needed.

> I think static files should not be writable instead, so every file under
> /usr (and /bin, /sbin, /lib*; or everything dpkg installs that is not a
> conffile) should have 444 (or 555).

I assume this is in support of systems, containers, or jails where UID 0
may not have CAP_FOWNER?

The basic argument makes sense to me, but this is the sort of change where
we'll need to figure out a transition strategy coordinated across multiple
packages, since this behavior is encoded in a lot of places.  Maybe it
would make sense for Guillem to weigh in first and indicate whether this
would be a problem on the dpkg side and if he sees any concerns.  Copying
debian-dpkg@lists for that.

-- 
Russ Allbery (r...@debian.org)  

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Ansgar]

Package: debian-policy

Hi,

10.9 Permissions and owners currently says

| Files should be owned by root:root, and made writable only by the
| owner and universally readable (and executable, if appropriate),
| that is mode 644 or 755."

However most files shouldn't be modified as modifications will just be
lost (e.g. everything installed by the package manager that isn't
handled as a conffile).  It also gives more permissions than the
minimum needed.

I think static files should not be writable instead, so every file
under /usr (and /bin, /sbin, /lib*; or everything dpkg installs that is
not a conffile) should have 444 (or 555).

Ansgar