Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforonaccess scanning

From: david
Date: Fri Aug 15 2008 - 01:23:28 EST


On Thu, 14 Aug 2008, Eric Paris wrote:

But Pavel is raising a good question. In Eric's proposed threat
model, he claimed the only thing that he was trying to solve was
"scanning". Just file scanning. That implies no root privileges, but
it also implied that he wasn't worried about malware running with user
privileges, either. Presumbly, that would be caught and stopped by
the file scanner before the malware had a chance to run; that is the
execve(2) system call would also be blocked until the executable was
scanned.

So if that is the threat model, then the only thing libmalware.so
doesn't solve is knfsd access, and it should be evaluated on that
basis. If the threat model *does* include malware which is **not**
caught by the AV scanner, and is running with user privileges, then
there are a whole host of other attacks that we have to worry about.
So let's be real clear, up front, what the threat model is, and avoid
changing the model around to rule out solutions that don't fit the
initially preconceived one. That's how you get to the TSA
confiscating water bottles in airport security lines.

No, I'm not claiming to protect against running processes. I'll leave
that for SELinux.

I haven't seen this supposed libmalware.so so take anything I say with a
grain of sand. But I take it that the solutions to the problems are
'don't do that.'

libmalware.so is shorthand for 'have a userspace library do the scanning and handle the open'

aka malware is allowed to flow freely across linux nfs servers. Great,
I'm sure corperate IT organizations are going to love knowing there
isn't a darn thing they can do to protect their nfs server from being
storage grounds other than hope they can control all of the border.

nfs isn't secure anyway so you better control the border.

it's only the kernel nfs daemon that won't use the library, so the answer is don't use that daemon. I beleive that there is a FUSE NFS option, or if nothing else, mount a filesystem with FUSE (linked against libmalware.so) and then export the result vi knfsd.

And I still don't get this 'mmap problem' that I don't solve that
libmalware magically solves. What? don't use mmap? I certainly hope
not.

libmalware can intercept the mmap call and decide to either prohibit it, copy the file so that the program is operating from it's own copy, or do something else (all dependant on policy, as defined in userspace for this library)

Are we seriously considering that the right thing to do is to try to
push malware scanning to every project on sourceforge? At least putting
a solution inside glibc wasn't completely insane, I just think for
numerous reasons we've seen on list for the last 2 weeks not a better
idea. In any case, having an application have to make special calls to
handle 'untrusted' data is basically like turning the keys to the castle
over on every exploit. No, I might not make promises about subverted
applications, but that doesn't mean I have to just open all the doors.
And anything that requires explicit application help is just that. Talk
about theater.

libmalware.so and a modified glibc are not mutually exclusive. you distros could offer versions of glibc that include libmalware.

again, libmalware.so is not referring to any specific body of code, it's referring to the concept that the handling of open/mmap/read/etc and scanning is done via a userspace library rather then by the kernel. if everyone can agree on that concept then hashing out the details of _which_ library it gets put in is a smaller detail.

this isn't designed to require every app that wants this protection to have to change it's code.

David lang
--
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/