LWN: Comments on "Critical Linux security API is still a kludge (Inquirer)"

Propriatory Anti-virus worse then Viruses.

orospakr — Tue, 24 Oct 2006 18:17:23 +0000

Actually, it wouldn't be quite the same thing, because I think the special capability that the AV vendors on Windows get is blocking the application while the AV scans the file. If the file turns out to be malicious, it would simply cause the read operation to fail.

An inotify-based AV scanner would introduce a race condition. The AV would pick up the virus, sure, but if the file were executed (or perhaps loaded into a vulnerable user application with a buffer overflow or similar) in the meantime, it would already be too late. In the case of a write-based inotify AV scanner, the file might get executed before the AV scanner checking the written file had completed its task.

That said, the REAL solution here is to simply *not run untrusted code* on your computer, unless it's done in a contained jail/vm/emulator environment.

Untrusted data files (perhaps evil word processing documents with macro viruses, buffer overflow exploits, etc.) should be scanned with the AV tool as they come in via the channel from the outside world *before* they touch any other trusted system components.

Critical Linux security API is still a kludge (Inquirer)

nlucas — Tue, 24 Oct 2006 18:12:42 +0000

It's now common on most countries to only allow people to drive with a driver's license.

Does it make roads saffer? Sure (and I would imagine a LOT saffer than before)
Does it make roads imune to accidents because of bad drivers? Not a chance.

There will always be bad drivers and no global education will fix that (unless restricting driving only to the safest ones, automatically making driving a "previledge" only to a subset of the population).

I don't see any difference between this and computer users.

Critical Linux security API is still a kludge (Inquirer)

nix — Tue, 24 Oct 2006 16:19:49 +0000

Hooking glibc's exec() wouldn't help for infected shared objects (likely to be a common target in any case, at least if viruses were actually a problem, which of course they aren't: infect one shared library and *bang* you've just got N executables too).

And of course shared libraries are mmap()ed in by ld.so (well, so is the executable, but you can tell what that's called statically: finding out the total set of shared libraries a program will use is impossible in the general case because of dlopen(), and indeed anything reimplementing dlopen() itself via mmap(), or via open() and read() into a prepared mmap()ed area.)

It has many of the same fundamental flaws as does digsig: it'll stop everyone but the determined attackers it's most useful to stop. (I'd like digsig to work as well but unfortunately it's one of those tools that only works until a single malware author works around it).

scanning on write

nix — Tue, 24 Oct 2006 16:14:37 +0000

- program A mmap()s foo.so
- nasty program B mmap()s foo.so and infects it
- program A now sees the virus-infected pages and so is magically infected too

So yes, you have to scan on each write: at least on each write of a file opened by more than one process.

Critical Linux security API is still a kludge (Inquirer)

arjan — Tue, 24 Oct 2006 14:27:07 +0000

fuse doesn't do good enough mmap for virus scanners.
fuse only gets to see the mmap page (when written to) at the final commit to the fs; but before that it has been in the VM for a LONG time, and visible to all other apps that have that file open. So the virus evil can already have taken place....

(and before you say "but the other app scans on open", at the time that app opened the file it may well not have been infected yet; many apps have .so files open as mmap for a really long time, weeks if not months)

Critical Linux security API is still a kludge (Inquirer)

madscientist — Tue, 24 Oct 2006 12:00:34 +0000

> Anyway, I'd be surprised if they didn't need to patch the kernel to get
> their syscall hooks in place.

I didn't try to build it but I read the install instructions before I posted. As far as I can tell they do NOT patch the kernel. They're just building an out-of-the-tree kernel loadable module, nothing more.

Of course, I could have missed something.

Critical Linux security API is still a kludge (Inquirer)

job — Tue, 24 Oct 2006 11:53:32 +0000

Why WOULD you want to check every file access? I would be surprised if Windows virus scanners this, it would be unbearably slow. What you probably want is to check all files treated as executable code, by hooking the exec call in libc.

Of course, evil code could relocate specific portions in data files, and by directly calling the kernel to execute them bypass the check. But this would be trivial by mmaping those parts in executable space anyway.

It's not very different in nature from self-encrypting code. I think the scanners need to treat them the same way, by checking for the decrypting/execing/mmaping code to begin with. The in-kernel hook described sounds like a flawed design no matter how you look at it, and I am not the least surprised it's difficult to convince the kernel devs to let it in.

Critical Linux security API is still a kludge (Inquirer)

MisterIO — Tue, 24 Oct 2006 10:31:56 +0000

Well,it's true that it's wrong trying to treat the security issues statistically in general,because there will always be some new and different ways to attack your software,but what I really meant was : "Try to start addressing the most dangerous of all threats,that is ignorance!".Yeah,you could argue that it's an overwelming task to do,but I don't think so.For example you could start teaching IT(and security problems related to IT) in schools(from the very beginning) just like math or history or geography,because in the modern times IT is so widespread and so important that you should be taught about it!You need to know about how to use pcs,exactly as you need to know english(to me too,even though english is not the language of my country).Yes,it's not a quick solution to the problem,but in the long run it will be the most effective one.

Cause of virii

khim — Tue, 24 Oct 2006 07:19:54 +0000

As far as I can tell it all comes down to the fact that there are fewer Linux machines out there

That's not 100% true. If you count number of systems (including unattached systems) - then it's of course true, but if you count available bandwidth... How many ADSL Windows PC will you need to match just one 1GBit-connected Linux server ? If you'll cound available bandwidth (and that's what spam relay's are need, right?) then Linux is already more attractive target. And we do see attacks from that angle (sendmail worms few years back, PHP-worms today, etc). I fail to see how Dazuko will help anything there: it's way too easy to write PHP worm if you know the bug in it... You need to fix PHP to stop PHP worms!

The Inq is wrong

gdt — Tue, 24 Oct 2006 04:39:52 +0000

SAMBA and NFS need a way of checking stuff before getting/sending it via the network. This may be able to use the previous thing, but maybe not.

Samba already has the Virtual File System API that can be used for virus scanning (and multilevel storage and other neat stuff). See samba-vscan for an implementation of a virus scanner which uses VFS.

Other applications which handle data on behalf of Windows systems have similar APIs. Sendmail's milter springs to mind. Milter is now in Postfix too, so we are seeking a common API emerge between the various mail transfer agents.

The Inq's complaint is that a API vital to virus scanning files before they are seen by a Window's host is missing. But since Samba, sendmail and other software which passed data to Windows systems have such APIs, what's the beef?

The article is a vendor whinge to a naive journalist dressed up with a page-hit-seeking headline.

Cause of virii

ringerc — Tue, 24 Oct 2006 03:25:06 +0000

I disagree. While Microsoft's design decisions have not helped the virus issue at all (system & program files writable by all users; applications that automatically execute code coming from *email*), many viruses only explioit user stupidity.

I don't personally see how a trojan that asks a user to run it in order to "speed up their computer" or whatever and when run mails itsself to everyone in their addressbook is Microsoft's problem. Their involvement is limited to making it easy to send programs around and easy to run them.

For trojans (as opposed to worms and the even rarer old-school executable infecting viruses), which are the most common threat these days, I think Linux is probably less exposed largely beceause:

- It's harder to run a program you've been sent. You need to do more
than just double click.
- The variety of software used means that something like
scanning the user's addressbook becomes a rather non-trivial task.

But wait? What do all these trojans do? They don't just propagage - they set themselves up as backdoors to be used as spam relays etc. Is there anything that'd prevent that being done on Linux?

- User base. Why bother when there are all those Windows machines
just waiting to be exploited by their helpful users.

After all, adding some start-up code to .bash_login, .xinitrc or whatever isn't too hard, nor is building a neat little static executable that'll run on most distros. Networking isn't a big deal - an outbound IRC control channel where it "phones home" eliminates the firewall issue, and is how most of them work anyway. As far as I can tell it all comes down to the fact that there are fewer Linux machines out there and it's harder to get the user to actually run the trojan (since they need to do more than double-click).

Microsoft has a role here, but not IMO as big a role as people tend to make out. These days. They certianly did - the outlook worms, SMB worms etc were the result of plain bad security. These days, the user should take equal blame.

Critical Linux security API is still a kludge (Inquirer)

ringerc — Tue, 24 Oct 2006 03:15:32 +0000

The "statistical" approach to security is unworkable, as it presumes that the attacker / threat is independent of your protection measures and is random (in the statistical sense, not to mean of equal probability). This is not the case - as you change your protection measures, the _people_ creating these attacks will simply move on to target other areas. You won't significantly reduce the number of attacks / viruses etc out there, nor will you reduce the harm they do much.

The attacker only needs to find one hole - and they're *actively* *looking* *for* *it*. Blocking 85% of security issues is not sufficient in this context, and it's for this reason that computer security is so hard.

If the attackers didn't respond to security advances, then you argument would make sense.

Propriatory Anti-virus worse then Viruses.

drag — Tue, 24 Oct 2006 03:11:34 +0000

Ok... Doesn't your system already have a API for responding to file system events?

So setup a daemon to monitor inotify events on user-writable directories and run clamav (or favorite alternative) on files that got written to. That should be all you'd ever need.

PROBLEM SOLVED.

That's it. What else would you need?

Set it up as a service for KDE or Gnome. I am sure that the Beagle guys would be able to integrate it so that files get scanned when they get indexed. Something like that to make it efficient as possible, but the basic concept is very simple.

Oh and that isn't good enough and root gets infected then your screwed anyways.

Also somebody needs to point out to the author of that article that propriatory antivirus software has openned up more holes by running this complex crap as root then any thing remotely virus-like.

Critical Linux security API is still a kludge (Inquirer)

ringerc — Tue, 24 Oct 2006 03:07:35 +0000

It needs to intercept and modify the behaviour of system calls. That is not supported (by design) in the module interface - the kernel *must* be modified. There's a dirty hack that does it from modules anyway, but it's not a great idea and frowned upon.

Why the syscall table isn't available from modules seems to be largely a politicial issue. My impression is that the kernel devs don't want large extensions of the kernel that insert lots of hooks to be possible as modules - perhaps because of the whole closed-source module issue?

Anyway, I'd be surprised if they didn't need to patch the kernel to get their syscall hooks in place.

frothing at the mouth?

dark — Tue, 24 Oct 2006 02:00:23 +0000

The article seems fairly reasonable up until the "The future" section, where the author loses control somehow. Suddenly we get "stupid complications", and phrases like "stop this madness". I guess there's some pent-up anger involved.

I think the article is looking at the wrong level of abstraction. There's no problem with scanning for viruses on Linux systems—you can drop a virus scanner into your mail system with no hassle, and you could hook one up to your Samba server if you wanted to. Apparently there are some technical difficulties with scanning for viruses in exactly the same way as on Windows systems (which the author calls a "resident" scanner). Well... then do it some other way. Virus scanning is the feature, a particular way of implementing it is not.

I find the reference to it being 1996 amusing, since TSR (Terminate and Stay Resident) virus scanners are closer to 1986 technology. Oh, woe, Linux does things differently than an ancient tradition inherited from msdos ;)

scanning on write

skitching — Mon, 23 Oct 2006 22:55:41 +0000

Is it really necessary to scan on each write operation? It seems to me that scanning on close would be sufficient.

If there are concerns about having to rescan a very large file which has had just a small piece modified then the monitoring layer (FUSE-based or other) could keep a list of modified blocks to be scanned on close. How about an in-kernel module that simply exposes a list of changed block ids which a user-mode module could then check on close?

Of course this is rather asymmetrical to the read scanning, which does need to be done as data is read in order to catch bad data on mounted filesystems such as NFS, so maybe it's not such a good idea..

Antivirus is a bad solution to bad security.

i3839 — Mon, 23 Oct 2006 22:19:36 +0000

Monoculture invites havoc too. Diversity is good for other reasons too, and quite underrated.

Critical Linux security API is still a kludge (Inquirer)

mrshiny — Mon, 23 Oct 2006 20:36:10 +0000

You may be right, in that users are responsible (i.e. they are the actors that perpetrate) poor security. However asking the whole world to change its behaviour is generally a hard task. Lots of people who might even be ripe for switching to Linux can't, because of a windows app they need. And some apps on Windows still require admin privs (Bad PalmDesktop! No desert for you). But the point is that even good habits and a non-root user isn't enough to prevent viruses. It's only a matter of time before macro viruses and the like make themselves known in the Linux world; these don't require root privs to spread or cause damage. And asking every user to manually scan every file is madness since you already know users are ignorant and forgetful.

Basically what I'm trying to say is, a virus scanner is not a bad thing. Sure, it isn't perfect, but it helps, and like you said, brings you statistically closer to "secure". Users will always be ignorant. The computer needs to account for that, not the other way around.

Antivirus is a bad solution to bad security.

penguin — Mon, 23 Oct 2006 19:16:59 +0000

Antivirus isnt a solution to virii and worms. At best its a bandaid to mitigate the most widespread viruses. The problem is that the virii can get into the system and wreak havoc. If virii is common on the platform it is because something is inherently wrong with the security model. Virii is just a symptom, not the cause.

The cause is the holes are the bad design choices that let virii in to easy, thats where work should be done. SELinux, GRSecurity and apparmour are some techniques to strap on added security that i like. Them in conjunction with good base security makes for several layers of security. Antivirus does not add to security, it just mitigates already sighted and known threats. Any unknown virii just sails on through.

Windows needs antivirus because Microsoft doesnt give a rats behind about security. Linux can avoid this by focusing on better security instead of slapping on some bandaid afterwards. If Linux starts seeing more virii i would hate it if we ended up with antivirus because that solution has been tried for 10+ years without any success.

As for scanning for eg windows files in linux fileservers etc that should be done by hooking up to the daemon in question serving theese files, not the kernel.

Stacking IS allowed.

dwheeler — Mon, 23 Oct 2006 18:44:59 +0000

Stacking LSM modules IS allowed, just not in the way that you first consider.

When you install an LSM module, it explicitly takes over. If you want to have "stacked" modules, you need to FIRST install a "stacking" LSM module, and THEN install the other modules. The LSM interface was SPECIFICALLY designed to support this.

I wrote the first LSM stacking module. But it has now been taken over, and it's now the lsm-stacker project (I no longer have anything to do with it, other than being a fan of the concept). Unfortunately, this module is not currently in the main kernel tree... but that is the eventual intent.

Critical Linux security API is still a kludge (Inquirer)

bluefoxicy — Mon, 23 Oct 2006 18:29:52 +0000

Actions like read() and mmap() can go through FUSE; and if you mmap() a file on a FUSE file system the kernel has to ask FUSE what to do with it. Once the filter extensions hit FUSE mainline (Miklos says they will), you'll be able to reliably determine when a file has changed.

For network file systems like NFS or SMB, you'll have to scan accessed data each time it's pulled over; but incremental scanning is possible. Picture scanning an executable that adds viral code to .text called by _main(). The relocation pages are pulled over, relocations are done, functions in .init are run, some of .text is pulled over, _main() is entered. Now _main() tries to execute virus in a page that hasn't yet been accessed. As that page is brought over, it is scanned for a virus, which is located; the system refuses to give that page to the application, and the application segfaults.

Of course the whole incremental scanning part is conjecture; a proof of concept implementation would be nice.

Critical Linux security API is still a kludge (Inquirer)

MisterIO — Mon, 23 Oct 2006 18:27:43 +0000

This seems a really waste of time to me!The problem of security in the IT world shouldn't be treated in a theoretical way.It should be treated in a statistical way,i.e. you shouldn't try to create an absolutely secure system,because it's really easy to fail in that direction(there's nothing perfet!),you should try to eliminate the first and most important of all the threats to all pcs,that is ignorance!If people follow even the most basic security rules,they would eliminate the 85% and maybe more of all kind of viruses.In fact the most dangerous problem about windows(at least till windows xp, I don't know about vista)is that you are root by default!!!This is why unixes are more secure by default(well,at least if you don't write your root password in your user folder in a file like rootpassword.txt,but this too is an ignorance problem!).Anyway,you could say that if you consider an enterprise or some government office,you should do even more,but well,if you are one of those ones,and you have selinux,and all the other systems already present in Linux,you should't need anything more,because you would be in a really secure condition and the real problem would be people another time!Normally people don't even want to read the documentation of their tvs or dvd players,they sit on the sofa and try pushingthis or that button,normally succeding with the simpler tasks and not using the advanced ones.The majority of pc users have this approach with pcs too!but networked pcs are a complete different beast than tvs or dvd players,and if you don't make this clear to them,there will always be big problems,whatever you do to make their systems secure,because a system cannot be secure without being more difficult to use than a dvd player(at least in the near future)!
All this said,why should be a threat to have a windows program in a Linux filesystem?Correct me if I'm wrong,but if you really need to use Wine,you can use an antivirus to scan the program and then use Wine to execute it.If you use xen to run windows(on a cpu that can do that),well,why do you do that?do you really need to do that?I can't really think about an environment that should be really secure and that should need to use windows for anything!

Dazuko is a kludge

bluefoxicy — Mon, 23 Oct 2006 18:21:26 +0000

Dazuko is nice but it's honestly a kludge. The new FUSE API will include a "Filter" file system which allows the FUSE module to read underneath itself-- and see what it's mounted over. Using this functionality, file-level access control can be implemented exactly as with Dazuko; but so much more, like compression and encryption and new APIs, can also be placed by skilled programmers.

Because FUSE acts just like kernel code, blocking until it does its work, you can modify or block access to files. You can tell the calling process the file is owned by another user, or just isn't allowed to be opened for no real reason at all besides that you say so. Once filtering is added, the entire functionality of Dazuko will fall right under the FUSE API.

http://article.gmane.org/gmane.comp.file-systems.fuse.dev...

Critical Linux security API is still a kludge (Inquirer)

nix — Mon, 23 Oct 2006 16:30:57 +0000

The LSM API intentionally does not stack. Stacking LSM modules that only restrict access is *probably* safe, but how can you be sure that the consequences of ANDing two unrelated modules' constraints together is still secure?

(This annoys me, too, but the reasoning for banning stacking is an absolute killer...)

Dakuzo doesn't work 100%

nix — Mon, 23 Oct 2006 16:28:26 +0000

Well, they *could* check mmap()ed reads, at least, by scanning the file on every open(). But, no, checking writes is out of the question in the presence of mmap() (imagine the expense! two context switches and some sort of expensive check on every write to an mmap()ed region? Gah.)

Critical Linux security API is still a kludge (Inquirer)

ajross — Mon, 23 Oct 2006 16:18:56 +0000

[...] but how difficult could it be to tell the first module that loads (eg AppArmor) that it's okay to load dazuko too?

My reading of this statement in their FAQ is that it's just spin. It's very common for two security solutions to collide, and for very good design reasons. To an AV scanner, another AV scanner look an awful lot like a rootkit. Making them work together, in the open souce world, is called "collaboration," and it makes the software better for everyone.

And that seems to be exactly the step that the "Dazuko" jokers want to skip. The article was clearly a troll, and about some IMHO pretty questionable software.

Critical Linux security API is still a kludge (Inquirer)

AJWM — Mon, 23 Oct 2006 16:11:49 +0000

> To paraphrase, they don't like LSM because [...] they don't want to integrate with SELinux or AppArmor, which also use the hooks.

The linked FAQ implies that the presence of AppArmor somehow makes the LSM API unavailable to any other module. I don't know enough to judge - could someone provide or point to a description of the LSM API that explains why this might be so, or why dazuko is wrong? I can see why you wouldn't want a security API open to just anyone who asks, but how difficult could it be to tell the first module that loads (eg AppArmor) that it's okay to load dazuko too?

Dakuzo doesn't work 100%

arjan — Mon, 23 Oct 2006 15:59:53 +0000

The problem is that IT DOESN'T check every access, but only some.

So not only is that approach they take a root-kit like kludge, it's not even nearly watertight. The don't (and fundamentally cannot) check reads and writes that are done via mmap() for example.

A fundamentally different technical solution is needed, and it probably is going to need changes all over the OS.

A few things that I think are needed:
* An easy, standard way for an application like firefox to ask "I'm about to save/open/... this file, please scan it for me and tell me it's ok". This is needed for Firefox, but also OpenOffice, Evolution and anything else that works with untrusted content. Preventing malware content from entering this system in the first place like this is always going to be better than finding it later on (that doesn't mean that the other one isn't needed per se, just that if you can filter it earlier that's obviously superior).
This way needs to be standardized (glibc?) and easy to use, while the admin can plug in policies and tools.
* SAMBA and NFS need a way of checking stuff before getting/sending it via the network. This may be able to use the previous thing, but maybe not.
* Wine and the other stuff this guy mentions should use the same hooks as in 1)
* If you want to do kernel level hooks, you CAN. They're called "LSM" today. LSM is superior to syscall hooking because it operates at the ACTION rather than at the ENTRY POINT. (this is similar to putting your money in a safe rather than putting a bigger lock on your door... the later case is vulnerable because a burglar can just come through the window). But even LSM doesn't solve the mmap() gap, that one is going to be fundamentally hard if not impossible to solve in a way that doesn't make performance totally suck

Critical Linux security API is still a kludge (Inquirer)

nix — Mon, 23 Oct 2006 15:39:43 +0000

i.e., the title of the Inquirer article is right. It *is* a kludge.

The content of the article is wrong, though: mainlining it wouldn't make it any *less* of a kludge: the very thing it's trying to do is fundamentally kludgy.

Critical Linux security API is still a kludge (Inquirer)

nix — Mon, 23 Oct 2006 15:38:09 +0000

It also means that the things opening the files *block* until the dazuko-using application has gated access, which *at best* turns open() from a syscall requiring two ring transitions to one requiring four ring transitions and two context switches!

Doing this sort of thing using inotify is a total waste of time in the presence of network filesystems, SANs, and other filesystems that may be written by other than the local system.

But then this whole thing is a total waste of time anyway. Probably an LD_PRELOADed wrapper *is* the right thing: a wrapper wrapped specifically around WINE and those (very rare) other things that are actually at risk from Windows malware. Normally a clamav milter or something similar can do a better job anyway.

Critical Linux security API is still a kludge (Inquirer)

ajross — Mon, 23 Oct 2006 15:34:04 +0000

Never mind. I found the answer on Dazuko's FAQ:

href=http://www.dazuko.de/tgen.shtml#LSM

To paraphrase, they don't like LSM because (1) the API isn't stable between kernel versions and (2) they don't want to integrate with SELinux or AppArmor, which also use the hooks. These are the "culture shock" complaints you hear from a company used to doing business in the proprietary world: they don't understand that cooperation and collaboration is expected from them as the price of entry. Instead, they want the kernel to "get out of the way" so their product can work without interference, and the easiest way to make that hack work is to hook the syscall table.

Critical Linux security API is still a kludge (Inquirer)

ajross — Mon, 23 Oct 2006 15:26:40 +0000

Can someone explain why the existing LSM/SELinux hooks in the kernel are insufficient for this task? They can hook file access and execution already.

Critical Linux security API is still a kludge (Inquirer)

dvdeug — Mon, 23 Oct 2006 15:22:21 +0000

So what if Windows files end up on a Linux system? They aren't dangerous except when loaded on a Windows environment. To load a kernel module to scan everything is much like checking everything you bring home against airplane regulations; it's massive overkill, and causes aggrivation over things that just aren't dangerous.

More reasons why TFA is a troll:

tetromino — Mon, 23 Oct 2006 15:19:40 +0000

f the "dakuzo" thing was ready, well-done, and submitted to Linus, it would be on the tree. Someone can enlighten me why it isn't?

Because it's not well-done. It modifies the syscall table at runtime, and generally acts like a rootkit...

Critical Linux security API is still a kludge (Inquirer)

niner — Mon, 23 Oct 2006 15:19:32 +0000

Checking every access to every file is a giantic waste of resources and the reason why Windows is so unbearably slow, as soon as an anti virus product is installed.

Why check a file 15 times, when it didn't change? Using knotify to only check files that are new or have changed seems to be a much better idea to me. Besides, nowadays checking websites and emails seems to be much more important than files on the hard disk.

Critical Linux security API is still a kludge (Inquirer)

nix — Mon, 23 Oct 2006 15:06:52 +0000

The idea is that it checks *every* access to a given file, so single-process hacks like LD_PRELOAD aren't really good enough (e.g. what if something else needs a preloadable library? What about what it does to prelink?)

Doing it globally with /etc/ld.so.preload is possible, but using this deactivates prelink and thus generally kills performance (there's no point in fixing it, as /etc/ld.so.preload is very much a debugging hack only and *not* meant for production use).

Putting it in the kernel (perhaps in a stacked filesystem a-la unionfs, once that gets into the kernel) is probably a better idea.

More reasons why TFA is a troll:

hummassa — Mon, 23 Oct 2006 15:03:14 +0000

(1) if the "dakuzo" thing was ready, well-done, and submitted to Linus, it
would be on the tree. Someone can enlighten me why it isn't?
(2) on the distros sphere, any distro that wants to package dakuzo will do
so; modules tailored to the distro kernels are easy and *ubuntu, for
instance, distributes a dozen of those, each on its package. Besides, the
module can be included in the clamav package, if that is the case.
(3) in dapper, apt-cache search dakuzo does not ring a bell, and the
article implies that it should.
(4) on the antivirus software sphere, in the same way clamav/panda must
make a package for each distro they'll support, they can compile dakuzo
and distribute it together with their software, problem solved.

Critical Linux security API is still a kludge (Inquirer)

Gollum — Mon, 23 Oct 2006 14:40:57 +0000

How about using techniques like LD_PRELOAD, anyway?

Why does it have to be a kernel module in the first place?

Critical Linux security API is still a kludge (Inquirer)

ordonnateur — Mon, 23 Oct 2006 14:38:18 +0000

The Inquirer, an amusing redtop but not something I read for technical information.

Critical Linux security API is still a kludge (Inquirer)

mattdm — Mon, 23 Oct 2006 14:17:06 +0000

The author seems to believe that distro vendors should put it in their kernels, regardless of its upstream status.