Mailinglist Archive: opensuse (671 mails)

[Gary Hodder <vk2kcf@xxxxxxxxxx>]

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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx