lkml.org 
[lkml]   [2008]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [malware-list] TALPA - a threat model? well sorta.
From
Date
On Wed, 2008-08-13 at 22:23 +0100, Alan Cox wrote:
> On Wed, 13 Aug 2008 17:35:29 -0400
> Rik van Riel <riel@redhat.com> wrote:
>
> > On Wed, 13 Aug 2008 17:24:28 -0400
> > "Press, Jonathan" <Jonathan.Press@ca.com> wrote:
> >
> > > I may be missing something about your suggestion, but I don't see how
> > > this would work. Who does the chmod?
> >
> > Chmod is also not a solution to the hierarchical storage (or incremental
> > restore from backup) problem.
> >
> > I believe we really do need the block-on-open.
>
> The block on open is orthogonal really. Useful for HSM, useful for
> certain very primitive scanning but not much else that I can see.
>
> And its a minor mod to the security hooks to allow it as far as I can see

So here's where I run into trouble. Lets assume I want to be helpful
and engineer in a vacuum for this unknown HSM user as well. Clearly
file scanners need the file to be there which means the inode ("on disk"
kind) needs to be there and stuff like that. I assume that the HSM user
is going to need to hook long before these things even exist. Where
would they need to hook?

Should I just design for my own needs and include stacking and a
priority number and hopefully the HSM people can use it later? I don't
know the details of what might someday by needed for a project I know
nothing about *smile*

-Eric



\
 
 \ /
  Last update: 2008-08-15 05:29    [W:0.205 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site