Re: Bits from the release team: the plans for etch

[Gabor Gombas <gombasg@sztaki.hu>]

On Wed, Oct 26, 2005 at 03:50:36PM +0200, Javier Fernández-Sanguino Peńa wrote:

> Wrong. That is only true in the chown() case. Which is not a sensible thing
> to do. Daemons should be able to read their configuration files but they
> usually *don't* need to *write* them, so they should *not* own them.

That is true in general, but I've seen it enough times to say it is a
common administration mistake. Of course, you can say that if the admin
wants to shoot himself on the foot, let's give him a bigger gun...

> [ File with sensitive information ]
> - File is mode 640 and owned by root
> - File belongs to the 'X' group, if the group is shared across packages then
>   the group should not be removed (or created) by the daemon package.
> - Daemon 'D' belongs to the 'X' group, so he can read the file
> 
> Removal consequence: none. żWhy? if the file is *not* shared across packages,
> both the user, the group and the file should be removed _at_the_same_ time on purge.

Here you assume that the packaging system knows about all such files, but
that is simply not true. Simple example: a daemon that is capable of
TLS. Now, the admin generates a certificate/key pair, and modifies the
config file to use them. At this point, the packaging system has _zero_
knowledge that the cert/key files exist, so it can not remove them (and
even parsing the config file to locate them would be wrong, since those
files were generated by the admin therefore should never be removed by
the package).

Now, the key is likely having permission 640, owned by root, group is
the daemon's group. This group is _not_ shared, so when the daemon is
removed, the group is removed as well, and the next package installed
that needs a system user/group will re-use the GID, thus it will have
access to the private key.

And this is a security problem, since having access to the private key
even after the daemon has been removed can allow an attacker to decrypt
network traffic recorded in the past.

Also, even if the file is shared by multiple packages, there is _no_
guarantee that it uses a shared group. ACLs are supported by Linux for
quite some time now. In fact it is quite reasonable to have a
sensitive file being owned by root:root, having default access mask
0600, but granting read permission to other selected users via
ACLs. This solution scales much better than creating a new group for
every possible sharing combination.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------