Mark - Syminet wrote: > We too were bit by this bug today. I don't think this is a bug. I think this is a natural consequence of running the command as root. There are many things that people should never do as root because files owned by root are not manageable by non-root users afterward. Root is very powerful. With great power comes great responsibility.
Basically there are a few choices. 1. Action: Run the command as root. Consequence: People will file bug reports that the action is being run by root and root actions should be limited. 2. Action: Run the command as a non-root user. Consequence: People will file bug reports that they ran the command as root and then can't run the command as non-root. 3. Action: Use a permissive umask so that files are writable by anyone. Consequence: People will file bug reports that the file permissions are too permissive. In all cases there is no way to make everyone happy. I would be okay with the previously suggested action of adding a check to exit with an error if sa-update is run as root. Although I am sure that someone somewhere would be broken by this. (I have been there myself with aide's config before.) I think we should add checks to sa-update to complain loudly if it can't update its files. This would be suitable for passing upstream too and so we wouldn't need to diverge from upstream. It seems like what it should be doing already. If someone runs sa-update as root then fine. But then later when cron fires off sa-update as debian-spamd then it would complain loudly which would end up as email. I believe any admin using spamassassin should have email configured. If anyone runs spamassassin but does not configure email then I don't know what to say. > Fixed with the following commands: > > chown -R debian-spamd:debian-spamd /etc/spamassassin /var/lib/spamassassin Yes. > However, I'm confused because running the cronjob as the debian-spamd > pseudo-user seems to have accomplished two things, neither of which > are good: > > 1) Greatly increased the privileges of the debian-spamd pseudo-user, > by giving it carte-blanche write access to /etc/spamassassin and No because /etc/spamassassin is not writable by the debian-spamd user. The sa-update running by cron can't ever modify it. > /var/lib/spamassassin Yes because sa-update must be able to write somewhere. This is contained into just that one directory. The entire point of using the non-root user is to create a security layer to contain it to just that one directory. Running as root allows it to write anywhere. Running as debian-spamd contains it to just that location. > 2) Silently breaks every system out there where someone runs sa-update > as root, to make sure the rules are updating properly. See the above set of possibilities. No matter what you choose to do there will be the opposite viewpoint voiced in a bug report. Personally I think the current default of using a debian-spamd user makes the most sense. It creates a security layer. It avoids running this process that doesn't need to be root as root removing one attack surface for the system. > #2 is particularly insidious because the result is that spamassassin > increasingly loses it's effectiveness over time, until it's no longer > doing it's job at all. That appears to me to be an upstream deficiency of sa-update. It should complain with errors and error exit codes. > I'm honestly curious - what precisely is the rationale behind the decision > to make the spamassassin cronjob run as the debian-spamd pseudo-user? > There must be some benefit I am not seeing? The process does not need root priviledge to run. Running processes, especially those that interact with the hostile Internet, as root creates opportunities for attack. It is considered good programming practice to avoid running root unless it is necessary. Conversely it is considered bad practice to run processes as root that don't need root priviledge. I don't know about spamassassin but most Debian packages that run as root but don't need to get bug reports filed againsted them tagged security if they run as root unnecessarily. It is considered bad hygiene in this modern day hostile world. For example lets assume that someone finds an exploitable buffer overflow attack in the code. If the code is running as root then they can exploit it to become root on the machine. Since root can do anything then all files on the machine are suspect. At that point the entire machine is compromised. Your only option is to re-install from known good pristine sources and restore data from backup from before the attack. If the code is running as debian-spamd then the only place it can write to is /var/lib/spamassassin and only that directory needs to be cleaned. Running as a non-root user greatly limits the ability of an attacker after a compromise. Bob
signature.asc
Description: Digital signature
