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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
