Re: TALPA - a threat model? well sorta.

From: tvrtko . ursulin
Date: Fri Aug 15 2008 - 06:45:50 EST


Helge Hafting wrote on 15/08/2008 11:07:48:

> It seems to me that this "scan on file open" business is the
> wrong way to do things - because it reduces performance.

It can never be free - what ever you do it has to happen some time and
that can and will clash with something else. So your reason why it is
wrong is a bit to simplistic.

> If you scan on file open, then your security sw is too late and
> getting in the way.
>
> It is better to scan in advance. Most machines has lots of idle time.
> Use that time to scan in advance, and mark the files as "clean".
>
> A "clean" file can be opened without further checking anytime - giving
> normal high performance. A file that gets written to becomes "dirty"
> until checked again. Some mechanism for making a clean copy of a
> clean file might help avoid excessive "dirtying".
>
> "Scan on open" might still be useful for cases when the system
> haven't kept up with writing, but please don't aim to have
> this be the _primary_ mode of scanning. A file server
> where most of the stuff is pre-scanned will likely perform much better
> than one scanning everything on open.

The first thing you have to make clear is whether in your vision inode
clean-dirty-unknown status is persistent or not? But in any case I think
you are making a problem where there isn't one, think about it a bit.

But the idea about the ability to make a clean copy is interesting. So we
would need a copy done without userspace intervention and preserving the
inode cache status alongside it. Maybe splice or tee could easily do it?
Although I am not sure how often copying would happen and whether this
would be such a gain.

--
Tvrtko A. Ursulin
Senior Software Engineer, Sophos

"Views and opinions expressed in this email are strictly those of the
author.
The contents has not been reviewed or approved by Sophos."


Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/