Gary Hodder said the following on 06/08/2011 07:43 AM:
So with md5sum a file can be modified then put back to the original state before the next scan and md5sum wont pick that up.
Thanks Gary.
In one sense this is no different from the traditional hacker-security spiral. So long as the "bad guy" has adequate access power he can keep moving ahead of you. The only way you are going to be able to address this is to STRUCTURE the directories and files so that there is a clear separation between what can be changed ad-hoc and what can't be .... an by whom. Yes, Linux access controls are up to this, probably without even using extended ACL. You need to think in terms of GROUPS rather than simply "everyone" and "root". You need to remember that many of the operations you've talked about relate to directory rather than file access. So long as the directories concerned are writeable by "other" none of the techniques discussed are solid enough to escape subversion. As you say, the perpetrator can always keep a copy of the original and restore it, then use 'touch' to reset the times. You need to apply access controls to directories and that will mean restructuring some of the 'hierarchy'. All that being said, there are two other avenues worth looking at. The first amounts to logging. If this is being done with a shell, then there will be a shell history. Yes, the perpetrator can zap that file, but doing so is also evidence. I'm sure you can figure a way to make his .bash_history "append only" or mirror it to something impermeable. Suggestions, people? There are other ways of command logging, and failing that, a restricted shell. A menu is the ultimate restricted shell: you can only do what's in the menu. The second is a bit more extensive. Ultimately this use of the file system is treating it as a database. If you re-implemented it s a database then the set of commands, the logging and the access control would be different and possibly more constrained. This is worth looking at as a mental exercise since it will make you think about the roles and access and how they can be applied to the file system model. -- If you need to be told what your values are the implication is that you don't hold them right now. If you hold your values strongly enough, you don't need to print them out and stick them on a wall. If everyone shares them, they don't need to read them off a wall, either. -- Marcus J. Ranum -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org