On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote:
> On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a wrote:
>
> > That really depends on the daemon itself don't you think? There's a number of
> > daemons that don't create any file at all or, if they do, are created
> > only on a given directory which is removed on purge. In these cases, removing
> > the user on postrm's purge might make sense. As I said, that would be an
> > option.
>
> It is still possible that those daemons _read_ some files (e.g. config
> files), and the admin did a chown/chgrp to the daemon's user. Removing
> the user and reusing the UID/GID will suddenly make those files
> accessible for a random new package which may not be intended at all.
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. The
reasoning for this is that if a security vulnerability is found that affects
the daemon, and it can write to its configuration file, then you are
introducing additional risks beyond the vulnerability itself. Think for
example:
- a chrooted() FTP server that can write to its configuration files or to the
applications in the chroot
- a web server that can write in its web page space area.
- a SSH server that can write to sshd_config (and, consequently, can enable
subsystems, authentication methods or remove limitations set by the admin)
If you find daemons which have their configuration files chown'ed to them
withouth there being a need to write to, please file a bug.
Now, baring the chown() case, you have two think of two type of configuration
files: those that hold sensitive information and those that do not. If they
don't hold sensitive information then you make those world readable, if they
do then you use a group, which can be shared by different packages or used by
only one package.
Here's an analysis of different situations for configuration files under
those premises:
[ 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.
If the file is shared across packages (and is not a configuration file of the
daemon package), removal (or purge) of the daemon cannot lead to the removal
of the shared group. In either case, the file is not orphaned.
¿Can a new system daemon read the file?: no, unless he is added to the 'X'
group.
[ File without sensitive information ]
- File is mode 644 and owned by root, and belongs to 'root' group or
any other generic group ('adm')
- Daemon 'D' can read the file (due to it being world-readable)
Removal consequence: none, the file does not belong to the daemon user or its
group in any way, so it being remove cannot orphan the file.
¿Can a new system daemon read the file? Of course, the file is mode 644
The only situation where removing a daemon user is an issue is when the files
have either:
a- been created by the daemon through its normal operation
b- been created by the root user when impersonating the daemon
If the files hold to a) and are _not_ configuration files, log files, or
state files (i.e. under /var/run/, /var/state/, etc.) which should be removed
on purge as defined per policy, then the daemon should *not* be removed on
purge. This is the case of, for example, an MTA, which will create queue
files and spool files in normal operation.
If all the files in a) are purged and only b) remains as a possibility then
have the admin make a decission (and default to 'yes, remove' if appropiate)
Regards
Javier
Attachment:
signature.asc
Description: Digital signature