Hi. As already suggested by the rkhunter documentation, the tmp-dir /var/lib/rkhunter/tmp/ should have tight permissions. group-rights should be removed even for the root group IMO. As sysadmins may have deliberately removed this for some files copied there. Cheers, Chris.
Le dimanche 15 août 2010 à 18:06:14 (+0200), Christoph Anton Mitterer a écrit : Hi, The tmp directory keeps the default rights defined by upstream. You are right, though I would then better check that the files are copied to this directory using either 'cp -p' or 'cp -a', what do you think? This is already the case for the passwd and group files which are dealt with in the postinst script. Cheers, Julien
Le dimanche 15 août 2010 à 18:06:14 (+0200), Christoph Anton Mitterer a écrit : Hi, The tmp directory keeps the default rights defined by upstream. You are right, though I would then better check that the files are copied to this directory using either 'cp -p' or 'cp -a', what do you think? This is already the case for the passwd and group files which are dealt with in the postinst script. Cheers, Julien
Then we should perhaps try to get this done upstream (too)?! Well I'd use -a,... but nevertheless change the rights of the dir itslef.... why having something more open than needed? Cheers, Chris.
Le mardi 17 août 2010 à 15:06:56 (+0200), Julien Valroff a écrit : I have checked this carefully, and I confirm rkhunter uses "cp -f -p" to copy files to the tmp directory. I hence close this bug report, feel free to re-open it in case you disagree. Cheers, Julien
Le mardi 17 août 2010 à 15:06:56 (+0200), Julien Valroff a écrit : I have checked this carefully, and I confirm rkhunter uses "cp -f -p" to copy files to the tmp directory. I hence close this bug report, feel free to re-open it in case you disagree. Cheers, Julien
Le mardi 17 août 2010 à 21:25:30 (+0200), Christoph Anton Mitterer a écrit : They are reluctant on changing this. As far as I remember of a previous discussion, the current permissions were set after a real conscious decision. Well, upstream use -p but that's enough for your concern, am I right? Security through obscurity? ;) I am really not against this, but I do not see what it would bring. I am also reluctant in adding such specific patches which upstream would never merge. Cheers, Julien
I'll have a look at this. Well... -p will loose any SELinux stuff, and perhaps also ACLs? Might be not the best idea... e.g. protecting stuff like passwd via them,... and then it get's dropped.. Don't think so... it's a common rule in security to just open as much as strictly required.... even if for the moment something would be still secure when being more open,... this could quickly change later and nobody remembers... Well I didn't claim that I have a concrete example where the current way is problematic,.. but this doesn't mean that there aren't any ;) I do however not understand what upstream has against this?! Cheers, Chris.
reopen 593120 retitle 593120 security of files copied by rkhunter forwarded 593120 https://sourceforge.net/p/rkhunter/bugs/121/ tags 593120 + security severity 593120 important stop Hi Julien, et al. Now that the new upstream version got into Debian I've stumbled again over this issue. I think you haven't answered my last mail back then and I oversaw it when this bug got closed and archived. As you can see I've forwarded both problems now upstream, but if they shouldn't react I still think we should. As I state in the upstream bug: 1) We cannot assume how the root group is used, and whether it is secure or not, to copy files which should be perhaps only in root-user readable directories to one that is also group-readable. In some cases even the filename itself could be security sensitive. 2) Not copying with -a (i.e. forgetting ACLs, XATTRs and SELinux context) may be security critical as well. Even XATTRs may be used by people to e.g. store integrity information in their file, or to mark files which e.g. should be handled more restrictively by programs. 3) Even more actually: The copying of files a long is in principle already a problem, since they may e.g. be copied from encrypted disks to unencrypted disks,... thereby being recoverable via digital forensics. For that reason, I think, a files should only be copied to a tmpfs which is mounted by rkhunter upon /var/lib/rkhunter/tmp/ (I'll add that to the upstream bug in a minute). Since both are IMHO quite clear security problems (even though perhaps not the most pressing ones,... well at least I have no direct exploit), I mark this as severity=important as well. Cheers, Chris.