GUI für AntiVir

Boe · 10 Apr. 2007

Hallo,
gibt es eine GUI für AntiVir über smart zum herunterladen?
Ich habe mir "antivir", "antivir-avguard" und "dazuko" über smart gezogen. Jetzt bin ich auf der Suche nach einer GUI. Ich möchte mir kein *tar.gz Paket von der www.free-av.de Seite holen. Ich hätte gern ein rpm Paket, wenn es denn eines gibt.

mfg Boe

revealed · 10 Apr. 2007

also schau mal dort:
http://www.linux-club.de/viewtopic.php?t=65226&highlight=dazuko
und da (falls du lieber Apparmor wie ich hast?):
http://www.linux-club.de/ftopic74211.html
und ganz interessant ist bestimmt auch:
AntiVir Forum
Aber ich frag mich n bissl, warum du fragst?
http://www.linux-club.de/viewtopic.php?p=379553#379553

Gruss

R

Boe · 10 Apr. 2007

danke für die schönen links, aber es ist unter keinem die antwort auf meine frage zu finden. beim mir läuft antivir problemlos mit dazuko ohne GUI!

Aber ich frag mich n bissl, warum du fragst?
http://www.linux-club.de/viewtopic.php?p=379553#379553

ich frage weil ich es wissen möchte

sonst würd ich nicht fragen wenn es mich nicht interessieren würde.
die anleitung kenn ich, aber wie schon geschrieben suche ich das GUI als rpm paket und nicht als tar.gz o.s.ä.

revealed · 10 Apr. 2007

re

http://www.linux-club.de/viewtopic.php?p=434054#434054

Ehm ich glaube die bekommt man per Paketmanager nicht? Glaube dazu müsstest du bei der Webpräsenz von AntiVir eine aktuelle Version herunterladen, und diese dann anstelle des SUSE rpm einbinden?

Also wäre es dann wohl dieses Tut.:
http://www.linux-club.de/viewtopic.php?t=65226&highlight=dazuko
?

Aber bedenke - s letzte mal als ich Apparmor und dazuko gleichzeitig
versucht hatte konnten die 2 Progs sich noch nicht ab.

Ich habe deswegen lieber Apparmor in Betrieb als AntiVir.
Siehe:
http://www.dazuko.org/tgen.shtml#SUSE (Englisch)

Recent SuSE distributions (SUSE Linux 10, SLES 10, SLED 10) include and use AppArmor by default, which is why other modules cannot access the LSM API. This means that it is not possible to use Dazuko in its default configuration on these systems (because Dazuko by default uses the LSM interface on Linux 2.6 kernels).

Wobei du, falls du dir Dazuko ab Version 2.3 bauen solltest oder sogar hast folgendes versuchen könntest: (Damit hab ich aber keinerlei Erfahrung):

Code:

As of version 2.3.0 of Dazuko, you can use syscall hooking as an alternative to LSM for Linux 2.6 systems. If you require AppArmor, then you will need to use the syscall hooking method. This must be specified when configuring Dazuko:

$ ./configure --enable-syscalls --mapfile=/path/to/mapfile

The mapfile (System.map) is usually located in /boot and has the kernel version as a suffix.

Das wäre quasi die Lösung für Apparmor/Dazuko gleichzeitig, wenn ich richtig verstanden habe.

So jetzt hab ichs auch nochmal versucht aber noch nicht installiert, das werde ich auch nicht, weil ich keinen bock habe den Kernel umzubauen:

Hier was ich gemacht habe, und warum ich nicht weitermache:

Code:

wild-thing:/opt/dazuko-2.3.3 # ./configure --enable-syscalls --mapfile=/boot/System.map-2.6.18.8-0.1-default

checking host system type... Linux
checking for make utility... ok (make)
checking for C compiler... ok (cc)
kernel source in /lib/modules/2.6.18.8-0.1-default/source... yes
kernel build source in /lib/modules/2.6.18.8-0.1-default/build... yes
acquiring Linux kernel code configuration... ok
checking if Linux is RSBAC patched... no
checking if devfs is enabled... no
discovered host system... Linux (2.6.18)
checking for System.map file... ok (/boot/System.map-2.6.18.8-0.1-default)
locating sys_call_table... ok (0xc02aa4e0)
checking sys_call_table status... read-only

IMPORTANT NOTE:
If you get a kernel panic or segmentation fault while loading
the Dazuko module, you will need to reboot and try to
configure Dazuko again with the --sct-readonly option.

locating do_execve... ok (0xc016e871)
identifying device API... ok
inspecting class type... ok (class)
inspecting suspend function... ok (suspend2)
checking whether __d_path() is exported... no (using local copy, dangerous)
inspecting task_struct structure... ok (using parent)
configure: creating Makefile
configure: creating library/Makefile
configure: creating example_c/Makefile

./configure successful

=======================
Configuration summary
=======================

module events = ON_OPEN ON_CLOSE ON_EXEC
devfs support = no
rsbac support = no
hooking via syscalls = yes
local __d_path() = yes (WARNING: dangerous for SMP kernels, see README.linux26)
module debug = no
library 1.x compatibility = yes

Kurzgesagt :/configure läuft sauber durch aber laut der README.26

Code:

kwrite README.linux26

Ist das dazuko modul für dpath mit MP Systemen nicht sicher? Deswegen sollte man die Kernel integrierte dpath nutzen, wozu der Kernel konfiguriert sein muss diese zu exportieren:
Herausfinden ob exportiert wird kann man das durch diesen Befehl:

Code:

grep __d_path /proc/kallsyms

Bei mir laut readme:

xxxxx t __d_path <= not exported

Also müsste ich den Kernel neubauen mit einem Patch.

Also für mich leider keine Lösung. Aber wohl durchaus lösbar. Aber man könnte ja bei SUSE anfragen, ob der Export der dpath bei der nächsten Kernelversion für MP Systeme mit "default" integriert werden könnte?

Falls das so einfach möglich wäre?

Das hier war jetzt unter Verwendung von;
dazuko-2.3.3.tar.gz
Und ich mach nicht weiter, weil ich habe einen Core2Duo | 32bit SUSE 10.2 | mit

Code:

Linux wild-thing 2.6.18.8-0.1-default #1 SMP Fri Mar 2 13:51:59 UTC 2007 i686 i686 i386 GNU/Linux

Und der Betrieb von dazuko wäre dann leider wegen dpath nicht Sicher.

edit:
So jetzt habts mich so weit... jetzt probier ich den Patch aus dem dazuko verzeichnis auch noch gerade... also ich jetzt den Sensors PATCH und den dazuko PATCH angelegt und baue gerade...
/edit

edit2:
Also irgendwie funktioniert der Patch wo da dabei ist nicht? Ich hab also die Sourcen gepatcht und dann:

Code:

make cloneconfig && make && make modules_install

Aber trotzdem wird nicht exportiert?
/edit2

edit3:
Nach ausführen des Patch:

Code:

patch /usr/src/linux-2.6.18.8-0.1/fs/dcache.c /opt/dazuko-2.3.3/patch_dpath.diff

Inhalt der /lib/modules/2.6.18.8-0.1-default/buld/fs/dcache.c.rej

Code:

***************
*** 1402,1408 ****
   *
   * "buflen" should be positive. Caller holds the dcache_lock.
   */
- static char * __d_path( struct dentry *dentry, struct vfsmount *vfsmnt,
  			struct dentry *root, struct vfsmount *rootmnt,
  			char *buffer, int buflen)
  {
--- 1402,1408 ----
   *
   * "buflen" should be positive. Caller holds the dcache_lock.
   */
+ char * __d_path( struct dentry *dentry, struct vfsmount *vfsmnt,
  			struct dentry *root, struct vfsmount *rootmnt,
  			char *buffer, int buflen)
  {
***************
*** 1785,1787 ****
  EXPORT_SYMBOL(shrink_dcache_anon);
  EXPORT_SYMBOL(shrink_dcache_parent);
  EXPORT_SYMBOL(shrink_dcache_sb);
--- 1785,1788 ----
  EXPORT_SYMBOL(shrink_dcache_anon);
  EXPORT_SYMBOL(shrink_dcache_parent);
  EXPORT_SYMBOL(shrink_dcache_sb);
+ EXPORT_SYMBOL(__d_path);

/edit3:
Also scheint einfach der Patch nicht zu funktionieren?
Ich habe dann im Anschluss mit

Code:

make cloneconfig && make && make modules_install

gebaut - weiss jemand, wo mein Fehler liegt?

hoffe geholfen zu gehabt Tut.

Ich werde mal wegen meinem Problem im Forum von AntiVir nachfragen.

Gruss

R

Boe · 10 Apr. 2007

ein bisschen zu viel info für mich

es hätte die info gereicht, dass es keine GUI als rpm gibt.

@dazuko & apparmor
ich habe apparmor löschen müssen um dazuko zum laufen zu bekommen. ehrlich gesagt wage ich nicht im kernel herum zu fummeln, da dies etwas zu hoch für mich ist.
sollten jemals apparmor und dazuko nebeneinander laufen können bin ich dafür offen. bis dahin setze ich auf dazuko+antivir als auf apparmor.

revealed · 10 Apr. 2007

Code:

sollten jemals apparmor und dazuko nebeneinander laufen können bin ich dafür offen

Das ist es ja --- es scheint ja möglich zu sein. Dazu müsste aber der Patch funktionieren :S

im prinzip liegt es wohl nur daran, dass der SUSE Kernel für MP eben etwas exportieren müsste, wenn es angefragt wird. Und bei dazuko liegt ein Patch dabei, der das lösen müsste. Aber der funktioniert irgendwie nicht? Oder ich hab dabei was falsch gemacht....

Mir war eben besonders deswegen eher die Sicherheit des SUSE System wichtiger, als ein Virenscanner für Windowsdateien?

Wenn ich eben die dazuko obendrein noch einfach so einbinden würde, würde ich meiner Meinung nach ein unsicheres Modul laden. Dieses wäre ja nur für Uni Processorsysteme geeingnet.

Also ich glaube der Virenscannert findet eher keine Schädlinge die für Linux schädlich sein könnten. Apparmor hingegen würde einen Schutz für Linux bilden?

Aber hast du ein GUI jetzt? Ich meine - kannst du bestätigen, dass man über Yast kein GUI mitinstalliert bekommt, sondern dann auf die Andere vom Internet zurückgreifen müsste?

Gruss

R

trustkill · 10 Apr. 2007

Mal eine ganz gewagte Frage:

Wozu benötigt man AntiVir wenn man OpenSUSE hat ?

revealed · 10 Apr. 2007

Wozu benötigt man AntiVir wenn man OpenSUSE hat ?

Wenn man beispielsweise ein heterogenes privates Heimnetzwerk hat, indem auch Emails und Dateien für Windowsclients über linuxrechner laufen, dann kann der AntiVir dort auch zum Schutz der Windowsdateien beitragen. Und wenn man beispielsweise sein Betriebssystem scannen möchte, ohne das es läuft, kann man dann von Linux aus die außer betrieb genommene Platte tiefenscannen. Wäre meine intention dabei.

Gruss

R

Boe · 11 Apr. 2007

ich würde gerne helfen, aber ich sehe nicht die fehlermeldung.

revealed · 11 Apr. 2007

naja in diesem Sinne gibt es komischer Weise auch garkeine...

das einzige was ich bieten kann ist:

wenn man sich dazuko runterläd -

dann ist darin die README.26 -

das entpackte Verzeichnis von dazuko liegt bei mir in opt und ich hab den "2.6.18.8-0.1-default" und installiert sind in sachen Kernel:

rpm -qa |grep kernel
kernel-source-2.6.18.8-0.1
kernel-syms-2.6.18.8-0.1
linux-kernel-headers-2.6.18.2-3
kernel-default-2.6.18.8-0.1

make gcc rpm util usw-- alles da -

Jedenfalls darin steht, man müsse bei MP Maschinen den kernel mit dem Patch aus der heruntergeladenen dazuko quelle versorgen.

Das habe ich gemacht mit diesen 2 Befehlen:

Code:

patch /usr/src/linux-2.6.18.8-0.1/fs/dcache.c /opt/dazuko-2.3.3/patch_dpath.diff

Und dann von /usr/src/linux-* aus:

Code:

make cloneconfig && make && make modules_install

Ergebnis:
Keine Fehlermeldung.

Nach einem Neustart - wird die Funktion mit dem Testbefehl noch nicht exportiert. Testbefehl:

Code:

grep __d_path /proc/kallsyms

gibt kleines

t __dpath

müsste aber eigendlich großes

T __dpath

geben.

also laut readme:

Code:

xxxxx T __d_path <= exported
xxxxx t __d_path <= not exported

Bei mir aber ein kleines "t" trotz Patch ohne Fehlermeldung.

Der Patch hat einfach nichts geändert. Dann hab ich versucht und versucht. Den Patch nochmal eingebunden und dann hab ich die meldung mit dieser ".rej" Datei gesehen. Den Inhalt kannst du oben sehen.

Also es wirkt fast so, als würde der Patch irgendwie überschrieben oder greift garnicht erst?

Oder hab ich das falsche Verzeichnis gepatcht?

Ok ich habe zusätzlich noch in einem ganz anderen Verzeichnis den SENSORS Patch hier speziell für meine Maschine:
http://www.linux-club.de/ftopic77454.html
Aber da bin ich mir sehr sicher, der hat nichts damit zu tun.

Ganz schlicht make usw läuft straight forward durch meckert nicht aber es bewirkt nichts, als würde der Patch von make durch etwas anderes überschrieben?

zu allerletzt, weil ich dann aufgehört hab mit probieren hab ich ein feierliches "make clean all" laufen lassen.

Also mir ist sehr klar bewusst was für eine Art Fehlermeldung du meinst. Aber es fehlen keine Quellen oder derartiges und es bricht mir auch nicht ab oder sowas.

Es läuft sauber durch -- funktioniert dann aber nicht.

Gruss

R

Boe · 11 Apr. 2007

die frage ist aber ob speziell der default kernel bei suse 10.2 auch gepatcht werden muss, da es eigentlich ein kernel ist, der smp unterstützt aber nicht umbedingt nur smp unterstützt sondern auch "ein-kern" rechner. eigentlich ein "hybrid" kernel.
versuch es mal ohne patch.

edit:

Es läuft sauber durch -- funktioniert dann aber nicht.

bezieht sich dieser satz auf das patchen oder auf das gleichzeitge anwerfen von dazuko und apparmor?

revealed · 11 Apr. 2007

bezieht sich dieser satz auf das patchen oder auf das gleichzeitge anwerfen von dazuko und apparmor?

erstmal nur auf das Patchen der Kernel - weil ich kann ja nicht weiter als bis ./configure bei dazuko, wenn dpath nicht vom Kernel exportiert wird.

AFAIK sagt mir das eigendlich auch, dass wenn dazuko vom SUSE buildservice auch das dazuko mitgebrachte dpath für uniprozessoren verwendet, dass eben dieses Modul dann nicht korrekt mit MP Systemen zusammenarbeiten kann. Völlig wurst, ob das jetzt ein Kernel ist, der singlecpu´s sowie mp´s abkann.

Vorher verzichte ich lieber auf AntiVir.

Anders sollte ich das eher als Frage formulieren - ich will nicht angreifend klingen. Ist in keinster Weise meine Absicht - Ich will nur, dass es auch richtig und wie vorgesehen läuft.

Ist das dazuko aus dem SUSE Buildservice für MP-Systeme mit dpath Exportfunktion konfiguriert?

Gruss

R

Boe · 11 Apr. 2007

Ist das dazuko aus dem SUSE Buildservice für MP-Systeme mit dpath Exportfunktion konfiguriert?

tja, das wüsste ich auch gerne, aber du kannst mal im openSuSE chat unter freenode mal nachfragen. vielleicht meldet sich jemand, der am bau des moduls mitgewirkt hat.

revealed · 11 Apr. 2007

hmmm, meinst du nicht, ich sollte eine Rückmeldung im AntiVir Forum abwarten und dann vielleicht die Supportmitarbeiter dort bitten, sich mit sachlicher Kompetenz mit dem SUSE Build Service auseinanderzusetzen?

Also ich für mich ist eigendlich der Novell Bugzilla kein Spielplatz, sonst würde ich das einfach direkt hier nachfragen:
https://bugzilla.novell.com/show_bug.cgi?id=224985

Aber ich poste nur ungern mit meinem realen Namen und dieser wird mir beim Bugzilla als Username aufgezwunden, deswegen werde ich das unterlassen.

Also ich würde höflichst darum bitten wollen, dass mir jemand entweder erklärt:
Das wie du zu machen ist unnötig.
oder
Der Patch müsste so aussehen, oder das haben sie falsch gemacht....

Ich möchte auch nicht unnötig IRC channels zuspammen.

Aber wenn ich die Aussage dort richtig interpretiere:

Yes, the syscall support is not used -- we use the LSM hook variant,
what means, that following changes does not apply (not in the binary
module):

Dann haben die das im kernel-default übersehen?:::

"t"

Gruss

R