From #gentoo-dev IRC: <willikins> Chainsaw: Package: app-antivirus/clamav Herd: net-mail, antivirus Maintainer: net-mail, antivirus <willikins> Chainsaw: (net-mail) eras, hattya, radhermit, robbat2 <willikins> Chainsaw: (antivirus) lordvan <Chainsaw> ^ Folks, is there a reason why we can't/won't PaX-mark the clam binaries please? <Chainsaw> I keep having to do this after every upgrade. It makes my amavisd-new instance a sad panda. Chainsaw: what pax flags are you using on the binaries, and we'll apply them in the ebuild if good.
I think this has been somewhat addressed in bugs #326199 and #376733. Per Anthony's comment #13 on the former, the "disabling JIT..." warning is nothing to worry about: it just means that clamav will fall back to the slower but less-troublesome interpreter. As I mention in comment #4 on the latter, the warnings are indeed quite scary, and it would be nice if we could hide them or (better) convince upstream to emit a less terrifying warning.
@mjo: Chainsaw still complained in IRC this past week about it, so I want to know what he's doing and why the prior stuff isn't enough for him (if he even knows about it).
as per https://forums.gentoo.org/viewtopic-t-974000-view-previous.html i am using "paxctl-ng -m /usr/sbin/clamd /usr/bin/freshclam /usr/bin/clamconf" and things *seem to work* (i have not done extensive testing yet as i have just started setting up this system) as a matter of fact though, all of these binaries do require MPROTECT disabled as you will get a warning otherwise: "LibClamAV Warning: RWX mapping denied: Can't allocate RWX Memory: Operation not permitted" as per bug 326199#c13 you cannot disable the cause of the warning sanely, so we'd have to either live with it or PAX mark it expecting that people would want it (then again, we don't set SELinux booleans either iirc and the JIT would require one (clamd_use_jit))
is this still a problem with current versions?
Still an issue: LibClamAV Warning: RWX mapping denied: Can't allocate RWX Memory: Operation not permitted LibClamAV Warning: Bytecode: disabling JIT because PaX is preventing 'mprotect' access. Run 'paxctl -cm <executable>' [5746685.050751] grsec: From <redacted>: denied RWX mmap of <anonymous mapping> by /usr/bin/clamscan[clamscan:9143] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:30025] uid/euid:0/0 gid/egid:0/0
I'm going to try to send this upstream again (new management). If they reject it, we should just patch out the warnings behind USE=hardened finally. Here's the plan: 1. Introduce a --with-pax flag to the ./configure script. 2. If --with-pax was given, then disable the "RWX mapping denied" warning in libclamav/c++/detect.cpp. 3. If --with-pax was given, downgrade the two PaX "disabling JIT..." warnings in libclamav/builtin_bytecodes.h to debug messages to hopefully hide them. Should upstream decline the patch, we could create our own patch behind USE=hardened that, 1. Deletes the "RWX mapping denied" warning unconditionally from libclamav/c++/detect.cpp. 2. Unconditionally downgrades the warning in builtin_bytecodes.h to a debug message -- this amounts to deleting two '^' characters.
Ha ha! There's an "#if 0" right in the middle of builtin_bytecodes.h, which explains why I've been tearing my hair out for the past few hours. Apparently the second half of that file is used to generate the first half (with the clamav bytecode compiler), and then the second half is entirely commented out. That means two things: 1. I hate everything. 2. Attempting to use a compile-time constant to change the behavior of that file isn't going to work, so I can't downgrade the JIT warning to a debug message. We could conceivably do it in a patch, though, if someone is confident enough in the resulting blob of bytecode. I'll still submit the first, simpler, half of my fix upstream. That at least eliminates the "RWX mapping denied" warnings that most people get from cron every night.
@antivirus: can we close this now? These warnings were always pretty harmless, and without a freely-available grsecurity/PaX kernel, I don't expect anyone to experience or fix them in the future.
closing this bug as @mjo suggested .. no point keeping the bug around with no freely available grsecurity anymore.
