![](https://seccdn.libravatar.org/avatar/913a26ee350bbb119f6c348c48f40b70.jpg?s=120&d=mm&r=g)
On Wed, 2011-06-08 at 08:07 -0400, Anton Aylward wrote:
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. --
Hi Anton, a little more history needed. I am the only one that has a shell account, the rest don't no what Linux is let alone use it. All access is by samba, the main comp (winblows) thats a player and also does automation needs full access to the music directories. When new material is added to the library you have to run a cataloger which makes a catalog in the top directory and a small file for each mp3 that contains cross fades levels etc. so the find song can find the new stuff. Its a no win situation, this thing has no security at all. I have setup a rivendell box but they are to scared to use it, might have to put the good stuff on it and force them onto it. Thanks Gary. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org