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 --------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]