lkml.org 
[lkml]   [2007]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Out of tree module using LSM
Hi!

> > Personally I admit I never quite saw the point of intercepting all
> > file accesses for everything. That will just always be slow as often
> > demonstrated on other operating systems and racey and unreliable too.
> > And at least the internal daemons should be already reasonably well
> > protected by standard (or beyond standard, like AA/SELinux etc.)
> > security measures, so e.g. it does not really make sense to intercept
> > all of your /etc file accesses and similar.
>
> Personally I don't know. I am often surprised when I hear what techniques
> the bad guys use and what is possible.
>
> Solution that we currently have is not so slow (btw you are free to try it
> out). And by working on a proper interface race and reliability issues
> should be solvable.

Really?

So what you are trying to do is 'application may never read bad
sequence of bits from disk', right?

Now, how do you propose to solve mmap(MAP_SHARED)? The app on the other cpu may
see the bad bits before kernel has chance to see them.

> > It might be better to identify the services (gateway, samba, file
> > server whatever) that are actually dealing with possible infected
> > "external" files and then define some generic interface that would
> > allow you to check those as the data appears.
> >
> > I would expect such an approach to perform better in the end and be more
> > reliable too.
> >
> > Note such a interface might well be user space only.
>
> That is fine for some classes of servers. But for some other and desktop
> more could be needed.

Andi's solution seems the only one that has chance to work _reliably_.

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


\
 
 \ /
  Last update: 2007-12-02 13:37    [W:0.103 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site