Re: [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning

[Peter Dolding]

On Tue, Aug 5, 2008 at 1:58 PM, Cliffe <cliffe@xxxxxx> wrote:
> Greg KH wrote:
>>
>> On Tue, Aug 05, 2008 at 11:01:59AM +0800, Cliffe wrote:
>>
>>>
>>> If we had stackable LSMs then the required functionality could simply be
>>> built into the LSM interface. Then the anti-malware would simply stack
>>> itself with other LSMs.
>>>
>>
>> Could it really?  How would such an interface work?
>>
>> Remember, the big issue here isn't the kernel "hooks", but the fact that
>> a lot of people are yet to be convinced that something like this needs
>> to be within the kernel itself.
>>
>> Perhaps we should dig up the proposals for the filesystem-notify type
>> patches, something like that might be all the majority of the virus
>> people need, as they want to just scan things for Windows viruses, not
>> Linux ones, and to do so "lazily" might be sufficient.
>>
>
> From memory Dazuko is a LSM designed for this purpose, although it cannot be
> used on systems running other LSMs due to the lack of stacking support. It
> is used by a bunch of anti-malware programs including ClamAV and AVG.

Sorry to say stacking support really does need to be taken with a grain of salt.

Deeper the stack worse the issue of creating system lag.

Anti-malware stacking into LSM adding there own hooks need to be
looked at as more of a problem than a solution.

Lets take a simple example of Dazuko.   It catches all filesystem
accesses and can alter them.   Side effect all protected documents by
the LSM could end up going threw Dazuko so if a flaw is in the anti
virus that can be exploited straight up complete system exposed.

So really LSM stacking is not the correct solution.   More correct
solution would be list out what features malware and virus scanners
need and extend LSM interfaces so the main LSM could control where the
antivirus/malware scanner was accessing.  Yes there are times you
don't want virus scanners or malware scanners seeing everything.

Containers is another issue around stacking.   Containers being added
to Linux are providing more and more controls.  Currently LSM's are
independent to this.   People have responded that it is light weight
virtualisation so dones not need the need to run a different LSM
secuirty construct inside a container.   Its that it is
virtualistation is why it kinda need to.

Now any stacking design of LSM's have to take into account the needs
of containers.

Of course prefered is no stacking for containers and some form of
cross LSM mapping.  Like prime kernel LSM being selinux,  OS contained
being smack so smack secuirty files coveted to selinux with host OS's
limitations applied so container maintains its secuirty.

Same could be applied to chroot's.   This is a common over site of the
current LSM model.   chroot or containers running different
distrobution inside there is no preformated  way of picking up the
secuirty.   Note could even be the same distrubtion different version
just at one point of time they changed secuirty systems.  So user is
running a chroot or a container to run a old application that is
needed.  But now its running without secuirty.    This is could become
a major issue in time.

So yes needs of stacking have some major headaches.  Its not just a
malware issue.

Peter Dolding
--
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/