info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Und die AV-Software-Ablehner hier haben dann doch Recht?
23 views
Skip to first unread message
Uwe Premer
Jun 4, 2012, 7:30:34 AM6/4/12
to
http://heise.de/-1589640
Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
erstellt worden seien, dass AV-Software einfach überrannt würde.
Heise meint zudem, dass wohl langsam auch nicht-staatliche AV-Ersteller
dermassen grosse Ressourcen zur Verfügung hätten, dass Entwicklungen von
Viren möglich seien, die von den AV-Herstellern nicht mehr entgegnet
werden könnten.
Die Frage ist, wo soll das letztendlich hinführen?
Uwe
Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
erstellt worden seien, dass AV-Software einfach überrannt würde.
Heise meint zudem, dass wohl langsam auch nicht-staatliche AV-Ersteller
dermassen grosse Ressourcen zur Verfügung hätten, dass Entwicklungen von
Viren möglich seien, die von den AV-Herstellern nicht mehr entgegnet
werden könnten.
Die Frage ist, wo soll das letztendlich hinführen?
Uwe
Lars Gebauer
Jun 4, 2012, 8:26:09 AM6/4/12
to
* Uwe Premer:
Einsicht ist der 1. Schritt zur Besserung?
| Der Virenexperte folgert aus den bisher bekannten F�llen, dass die
| Antivirenhersteller Ihre Nutzer zwar gegen allt�gliche Bedrohungen
| wie Bank-Trojaner, Key-Logger oder E-Mail-W�rmer sch�tzen k�nnen,
Na ja. Was man eben alles so "Schutz" nennt ...
| nicht jedoch gegen spezielle Angriffe, die von Staaten mit nahezu
| unlimitierten Budgets ausgehen.
Nicht das Budget ist das Problem, sondern die simple Tatsache, da� es
sich um Malware handelte, die sich h�chst unauff�llig verhielt. Eine
Malware, mit der massenhaft Computer infiziert werden und die irgendwas
tut, was jedem Anwender ziemlich schnell sauer aufst��t ist nat�rlich
bedeutend auff�lliger als eine Malware, die immer h�bsch unter dem Radar
bleibt.
Das ist aber nicht neu. Mit den g�ngigen Standardma�nahmen, beginnend
bei einer sinnvollen Konfiguration, konnte man sich schon immer gegen
die �blichen, ungerichteten Attacken sch�tzen. Ein gezielter Angriff
hingegen hat das Problem schon immer auf eine ganz andere Ebene gehoben.
> http://heise.de/-1589640
>
> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
> erstellt worden seien, dass AV-Software einfach �berrannt w�rde.
>
> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
Einsicht ist der 1. Schritt zur Besserung?
| Der Virenexperte folgert aus den bisher bekannten F�llen, dass die
| Antivirenhersteller Ihre Nutzer zwar gegen allt�gliche Bedrohungen
| wie Bank-Trojaner, Key-Logger oder E-Mail-W�rmer sch�tzen k�nnen,
Na ja. Was man eben alles so "Schutz" nennt ...
| nicht jedoch gegen spezielle Angriffe, die von Staaten mit nahezu
| unlimitierten Budgets ausgehen.
Nicht das Budget ist das Problem, sondern die simple Tatsache, da� es
sich um Malware handelte, die sich h�chst unauff�llig verhielt. Eine
Malware, mit der massenhaft Computer infiziert werden und die irgendwas
tut, was jedem Anwender ziemlich schnell sauer aufst��t ist nat�rlich
bedeutend auff�lliger als eine Malware, die immer h�bsch unter dem Radar
bleibt.
Das ist aber nicht neu. Mit den g�ngigen Standardma�nahmen, beginnend
bei einer sinnvollen Konfiguration, konnte man sich schon immer gegen
die �blichen, ungerichteten Attacken sch�tzen. Ein gezielter Angriff
hingegen hat das Problem schon immer auf eine ganz andere Ebene gehoben.
Uwe Premer
Jun 4, 2012, 8:51:03 AM6/4/12
to
Am Mon, 04 Jun 2012 14:26:09 +0200 schrieb Lars Gebauer:
> * Uwe Premer:
>> http://heise.de/-1589640
>>
>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>> erstellt worden seien, dass AV-Software einfach überrannt würde.
> * Uwe Premer:
>> http://heise.de/-1589640
>>
>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>
> Einsicht ist der 1. Schritt zur Besserung?
Keine Ahnung, ob die ein Einsehen haben.
> Einsicht ist der 1. Schritt zur Besserung?
>| nicht jedoch gegen spezielle Angriffe, die von Staaten mit nahezu
>| unlimitierten Budgets ausgehen.
>
> sich um Malware handelte, die sich höchst unauffällig verhielt.
Die hätten durch ihr riesiges Budget die Möglichkeit, ihre Malware gegen
alle auf dem Markt befindlichen AV-Programme ausführlich zu testen und
dann so zu optimieren, dass AV-Software chancenlos sei.
> Das ist aber nicht neu. Mit den gängigen Standardmaßnahmen, beginnend
> bei einer sinnvollen Konfiguration, konnte man sich schon immer gegen
> die üblichen, ungerichteten Attacken schützen.
Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
User-Account kaputt gemacht werden, was dann auch ärgerlich sein kann.
> Ein gezielter Angriff
> hingegen hat das Problem schon immer auf eine ganz andere Ebene gehoben.
Uwe
Jens Hektor
Jun 4, 2012, 9:22:47 AM6/4/12
to
Am 04.06.2012 14:26, schrieb Lars Gebauer:
> Nicht das Budget ist das Problem, sondern die simple Tatsache, daß es
> sich um Malware handelte, die sich höchst unauffällig verhielt.
Nicht nur das, sie war auch noch gültig signiert.
> Nicht das Budget ist das Problem, sondern die simple Tatsache, daß es
> sich um Malware handelte, die sich höchst unauffällig verhielt.
Nicht nur das, sie war auch noch gültig signiert.
Heinz-Mario Frühbeis
Jun 4, 2012, 9:26:04 AM6/4/12
to
"Uwe Premer"...
Nur weil einer Geld kann_ er sich Genie kaufen?
Wenn* einer wirklich Genie hätte, oder zu min. auch nur 'Sehr gut' in seiner
Arbeit wäre, dann würde er sich nicht verkaufen ...
> http://heise.de/-1589640
>
> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
> erstellt worden seien, dass AV-Software einfach überrannt würde.
Was in aller Welt hat denn immer das Geld mit Genie zu tun?
>
> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
> erstellt worden seien, dass AV-Software einfach überrannt würde.
Nur weil einer Geld kann_ er sich Genie kaufen?
Wenn* einer wirklich Genie hätte, oder zu min. auch nur 'Sehr gut' in seiner
Arbeit wäre, dann würde er sich nicht verkaufen ...
Uwe Premer
Jun 4, 2012, 10:21:12 AM6/4/12
to
Am Mon, 4 Jun 2012 15:26:04 +0200 schrieb Heinz-Mario Frühbeis:
> "Uwe Premer"...
>> http://heise.de/-1589640
>>
>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>> erstellt worden seien, dass AV-Software einfach überrannt würde.
>
> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
> Nur weil einer Geld kann_ er sich Genie kaufen?
Wenn du statt klammen 2 Programmierern gleich ein Team von 20 oder 50
> "Uwe Premer"...
>> http://heise.de/-1589640
>>
>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>> erstellt worden seien, dass AV-Software einfach überrannt würde.
>
> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
> Nur weil einer Geld kann_ er sich Genie kaufen?
Programmierern an so eine Aufgabe setzen kannst, wird das Ergebnis weit
effektiver.
Ich denke, das hat auch weit weniger mit "Genie" zu tun als einfach mit
Manpower.
Uwe
Stefan Kanthak
Jun 4, 2012, 10:23:54 AM6/4/12
to
"Uwe Premer" <m...@uwe-premer.de> schrieb:
> http://heise.de/-1589640
>
> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
> erstellt worden seien, dass AV-Software einfach überrannt würde.
Nein, das ist keineswegs der Grund!
Nicht nur F-Secure, sondern auch andere AV^WSchlangenoelproduzenten
hatten "Flame", "Stuxnet" und "Duqu" in ihren Datenbanken, aber haben
den Code oder das Verhalten nicht analysiert.
Fazit (mal wieder): auch gegen bekannte Schaedlinge schuetzt AV-Zeux
NICHT!
> Heise meint zudem, dass wohl langsam auch nicht-staatliche AV-Ersteller
> dermassen grosse Ressourcen zur Verfügung hätten, dass Entwicklungen von
> Viren möglich seien, die von den AV-Herstellern nicht mehr entgegnet
> werden könnten.
Auch das ist falsch: Botnetz-Betreiber produzieren seit Jahren im Tages-
oder Stundenrhythmus neue Varianten ihrer Schaedlinge und unterlaufen
damit KONTINUIERLICH die (signaturbasierte) Erkennung.
> Die Frage ist, wo soll das letztendlich hinführen?
ZUM AUFWACHEN! Und zur Besinnung auf WIRKSAME Schutzmassnahmen.
Nicht nur hier[TM] hilft restriktive Konfiguration und Verzicht auf
notorisch unsicher Software gegen Schaedlinge, egal ob [un]bekannt.
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
> http://heise.de/-1589640
>
> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
> erstellt worden seien, dass AV-Software einfach überrannt würde.
Nicht nur F-Secure, sondern auch andere AV^WSchlangenoelproduzenten
hatten "Flame", "Stuxnet" und "Duqu" in ihren Datenbanken, aber haben
den Code oder das Verhalten nicht analysiert.
Fazit (mal wieder): auch gegen bekannte Schaedlinge schuetzt AV-Zeux
NICHT!
> Heise meint zudem, dass wohl langsam auch nicht-staatliche AV-Ersteller
> dermassen grosse Ressourcen zur Verfügung hätten, dass Entwicklungen von
> Viren möglich seien, die von den AV-Herstellern nicht mehr entgegnet
> werden könnten.
oder Stundenrhythmus neue Varianten ihrer Schaedlinge und unterlaufen
damit KONTINUIERLICH die (signaturbasierte) Erkennung.
> Die Frage ist, wo soll das letztendlich hinführen?
Nicht nur hier[TM] hilft restriktive Konfiguration und Verzicht auf
notorisch unsicher Software gegen Schaedlinge, egal ob [un]bekannt.
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Lars Gebauer
Jun 4, 2012, 11:03:11 AM6/4/12
to
* Uwe Premer:
arbeitslos wäre hätte ich sogar die Zeit dazu. ;)
Nein, es war das unauffällige Verhalten, die niedrige Zahl der
infizierten Co9mputer in Kombination mit Gimmicks wie digitale Signatur
(wie Jens angemerkt hat).
Natürlich braucht man ein paar fähige Programmierer - aber so irrsinnig
teuer ist das auch nicht.
>> Das ist aber nicht neu. Mit den gängigen Standardmaßnahmen, beginnend
>> bei einer sinnvollen Konfiguration, konnte man sich schon immer gegen
>> die üblichen, ungerichteten Attacken schützen.
>
> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
> User-Account kaputt gemacht werden, was dann auch ärgerlich sein kann.
War doch kürzlich erst (wieder mal) (hier oder in einer der anderen
dcs.*-Gruppen) Thema. Auch dieses Risiko läßt sich eindämmen.
> Am Mon, 04 Jun 2012 14:26:09 +0200 schrieb Lars Gebauer:
>> Nicht das Budget ist das Problem, sondern die simple Tatsache, daß es
>> sich um Malware handelte, die sich höchst unauffällig verhielt.
>
> Die hätten durch ihr riesiges Budget die Möglichkeit, ihre Malware gegen
> alle auf dem Markt befindlichen AV-Programme ausführlich zu testen und
> dann so zu optimieren, dass AV-Software chancenlos sei.
Diese Möglichkeit habe ich auch ohne ein riesiges Budget. Wenn ich
>> Nicht das Budget ist das Problem, sondern die simple Tatsache, daß es
>> sich um Malware handelte, die sich höchst unauffällig verhielt.
>
> Die hätten durch ihr riesiges Budget die Möglichkeit, ihre Malware gegen
> alle auf dem Markt befindlichen AV-Programme ausführlich zu testen und
> dann so zu optimieren, dass AV-Software chancenlos sei.
arbeitslos wäre hätte ich sogar die Zeit dazu. ;)
Nein, es war das unauffällige Verhalten, die niedrige Zahl der
infizierten Co9mputer in Kombination mit Gimmicks wie digitale Signatur
(wie Jens angemerkt hat).
Natürlich braucht man ein paar fähige Programmierer - aber so irrsinnig
teuer ist das auch nicht.
>> Das ist aber nicht neu. Mit den gängigen Standardmaßnahmen, beginnend
>> bei einer sinnvollen Konfiguration, konnte man sich schon immer gegen
>> die üblichen, ungerichteten Attacken schützen.
>
> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
> User-Account kaputt gemacht werden, was dann auch ärgerlich sein kann.
dcs.*-Gruppen) Thema. Auch dieses Risiko läßt sich eindämmen.
Lars Gebauer
Jun 4, 2012, 11:05:33 AM6/4/12
to
* Heinz-Mario Frühbeis:
> Wenn* einer wirklich Genie hätte, oder zu min. auch nur 'Sehr gut' in seiner
> Arbeit wäre, dann würde er sich nicht verkaufen ...
Wie bitte? - Idealismus ist ja gut und schön. Sehr weit kommst Du mit
dieser Ansicht allerdings nicht.
> "Uwe Premer"...
>> http://heise.de/-1589640
>>
>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>> erstellt worden seien, dass AV-Software einfach überrannt würde.
>
> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
> Nur weil einer Geld kann_ er sich Genie kaufen?
Aber ja, das funktioniert erstaunlich häufig.
>> http://heise.de/-1589640
>>
>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>> erstellt worden seien, dass AV-Software einfach überrannt würde.
>
> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
> Nur weil einer Geld kann_ er sich Genie kaufen?
> Wenn* einer wirklich Genie hätte, oder zu min. auch nur 'Sehr gut' in seiner
> Arbeit wäre, dann würde er sich nicht verkaufen ...
dieser Ansicht allerdings nicht.
Uwe Premer
Jun 4, 2012, 11:47:39 AM6/4/12
to
Am Mon, 04 Jun 2012 17:03:11 +0200 schrieb Lars Gebauer:
> * Uwe Premer:
>> Am Mon, 04 Jun 2012 14:26:09 +0200 schrieb Lars Gebauer:
>>> Nicht das Budget ist das Problem, sondern die simple Tatsache, daß es
>>> sich um Malware handelte, die sich höchst unauffällig verhielt.
>>
>> Die hätten durch ihr riesiges Budget die Möglichkeit, ihre Malware gegen
>> alle auf dem Markt befindlichen AV-Programme ausführlich zu testen und
>> dann so zu optimieren, dass AV-Software chancenlos sei.
>
> Diese Möglichkeit habe ich auch ohne ein riesiges Budget. Wenn ich
> arbeitslos wäre hätte ich sogar die Zeit dazu. ;)
Schon. Aber dann muß natürlich auch entsprechendes Fach- und
> * Uwe Premer:
>> Am Mon, 04 Jun 2012 14:26:09 +0200 schrieb Lars Gebauer:
>>> Nicht das Budget ist das Problem, sondern die simple Tatsache, daß es
>>> sich um Malware handelte, die sich höchst unauffällig verhielt.
>>
>> Die hätten durch ihr riesiges Budget die Möglichkeit, ihre Malware gegen
>> alle auf dem Markt befindlichen AV-Programme ausführlich zu testen und
>> dann so zu optimieren, dass AV-Software chancenlos sei.
>
> Diese Möglichkeit habe ich auch ohne ein riesiges Budget. Wenn ich
> arbeitslos wäre hätte ich sogar die Zeit dazu. ;)
Insiderwissen da sein.
> Nein, es war das unauffällige Verhalten, die niedrige Zahl der
> infizierten Co9mputer in Kombination mit Gimmicks wie digitale Signatur
> (wie Jens angemerkt hat).
>> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
>> User-Account kaputt gemacht werden, was dann auch ärgerlich sein kann.
>
> War doch kürzlich erst (wieder mal) (hier oder in einer der anderen
> dcs.*-Gruppen) Thema. Auch dieses Risiko läßt sich eindämmen.
Hast du oder sonst Jemand mal die entsprechenden MIDs zu den jeweiligen
Thread-OPs?
Uwe
Lars Gebauer
Jun 4, 2012, 12:12:15 PM6/4/12
to
* Uwe Premer:
> Am Mon, 04 Jun 2012 17:03:11 +0200 schrieb Lars Gebauer:
>> * Uwe Premer:
> Am Mon, 04 Jun 2012 17:03:11 +0200 schrieb Lars Gebauer:
>> * Uwe Premer:
>>> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
>>> User-Account kaputt gemacht werden, was dann auch �rgerlich sein kann.
>>
>> War doch k�rzlich erst (wieder mal) (hier oder in einer der anderen
>> dcs.*-Gruppen) Thema. Auch dieses Risiko l��t sich eind�mmen.
>
> Interessant. Oder anders: w�rde mich interessieren.
> Hast du oder sonst Jemand mal die entsprechenden MIDs zu den jeweiligen
> Thread-OPs?
Suche einfach nach den Postings von Stefan Kanthak. Im wesentlichen geht
> Thread-OPs?
es hierum: Message-ID:
<4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
Helmut Hullen
Jun 4, 2012, 10:51:00 AM6/4/12
to
Hallo, Stefan,
Du meintest am 04.06.12:
> Nicht nur F-Secure, sondern auch andere AV^WSchlangenoelproduzenten
> hatten "Flame", "Stuxnet" und "Duqu" in ihren Datenbanken, aber haben
> den Code oder das Verhalten nicht analysiert.
> Fazit (mal wieder): auch gegen bekannte Schaedlinge schuetzt AV-Zeux
> NICHT!
Sie sch�tzt nicht gegen jede Schadsoftware.
Du verallgemeinerst mal wieder unzul�ssig.
Viele Gruesse!
Helmut
Du meintest am 04.06.12:
> Nicht nur F-Secure, sondern auch andere AV^WSchlangenoelproduzenten
> hatten "Flame", "Stuxnet" und "Duqu" in ihren Datenbanken, aber haben
> den Code oder das Verhalten nicht analysiert.
> Fazit (mal wieder): auch gegen bekannte Schaedlinge schuetzt AV-Zeux
> NICHT!
Du verallgemeinerst mal wieder unzul�ssig.
Viele Gruesse!
Helmut
Ansgar -59cobalt- Wiechers
Jun 4, 2012, 1:03:48 PM6/4/12
to
Siemens eingeschlossen). Wahr wird es dadurch allerdings nicht, wie man
an handelsüblichen Großprojekten leicht sehen kann. Software-Entwicklung
lässt sich nicht so trivial in die Breite skalieren.
cu
59cobalt
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
Ansgar -59cobalt- Wiechers
Jun 4, 2012, 1:05:28 PM6/4/12
to
Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
> "Uwe Premer" <m...@uwe-premer.de> schrieb:
ist, hat Avira ja gerade demonstriert.
> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>> Heise meint zudem, dass wohl langsam auch nicht-staatliche AV-Ersteller
>> dermassen grosse Ressourcen zur Verfügung hätten, dass Entwicklungen von
>> Viren möglich seien, die von den AV-Herstellern nicht mehr entgegnet
>> werden könnten.
>
> Auch das ist falsch: Botnetz-Betreiber produzieren seit Jahren im Tages-
> oder Stundenrhythmus neue Varianten ihrer Schaedlinge und unterlaufen
> damit KONTINUIERLICH die (signaturbasierte) Erkennung.
Und warum verhaltensbasierte Erkennung auch nicht so das Gelbe vom Ei
>> dermassen grosse Ressourcen zur Verfügung hätten, dass Entwicklungen von
>> Viren möglich seien, die von den AV-Herstellern nicht mehr entgegnet
>> werden könnten.
>
> Auch das ist falsch: Botnetz-Betreiber produzieren seit Jahren im Tages-
> oder Stundenrhythmus neue Varianten ihrer Schaedlinge und unterlaufen
> damit KONTINUIERLICH die (signaturbasierte) Erkennung.
ist, hat Avira ja gerade demonstriert.
Lars Gebauer
Jun 4, 2012, 1:04:18 PM6/4/12
to
* Helmut Hullen:
> Du verallgemeinerst mal wieder unzulässig.
Wenn man ja wüßte, gegen /welche/ Malware die Rouletteware denn so
schützt, dann wäre man ja mal einen Schritt weiter ...
>> Nicht nur F-Secure, sondern auch andere AV^WSchlangenoelproduzenten
>> hatten "Flame", "Stuxnet" und "Duqu" in ihren Datenbanken, aber haben
>> den Code oder das Verhalten nicht analysiert.
>
>> Fazit (mal wieder): auch gegen bekannte Schaedlinge schuetzt AV-Zeux
>> NICHT!
>
> Sie schützt nicht gegen jede Schadsoftware.
>> hatten "Flame", "Stuxnet" und "Duqu" in ihren Datenbanken, aber haben
>> den Code oder das Verhalten nicht analysiert.
>
>> Fazit (mal wieder): auch gegen bekannte Schaedlinge schuetzt AV-Zeux
>> NICHT!
>
> Du verallgemeinerst mal wieder unzulässig.
Wenn man ja wüßte, gegen /welche/ Malware die Rouletteware denn so
schützt, dann wäre man ja mal einen Schritt weiter ...
Uwe Premer
Jun 4, 2012, 1:24:37 PM6/4/12
to
Am Mon, 04 Jun 2012 18:12:15 +0200 schrieb Lars Gebauer:
> * Uwe Premer:
>> Am Mon, 04 Jun 2012 17:03:11 +0200 schrieb Lars Gebauer:
>>> * Uwe Premer:
>>>> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
> * Uwe Premer:
>> Am Mon, 04 Jun 2012 17:03:11 +0200 schrieb Lars Gebauer:
>>> * Uwe Premer:
>>>> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
>>>> User-Account kaputt gemacht werden, was dann auch ärgerlich sein kann.
>>>
>>> War doch kürzlich erst (wieder mal) (hier oder in einer der anderen
>>> dcs.*-Gruppen) Thema. Auch dieses Risiko läßt sich eindämmen.
>>
>> Interessant. Oder anders: würde mich interessieren.
>>>
>>> War doch kürzlich erst (wieder mal) (hier oder in einer der anderen
>>> dcs.*-Gruppen) Thema. Auch dieses Risiko läßt sich eindämmen.
>>
>> Hast du oder sonst Jemand mal die entsprechenden MIDs zu den jeweiligen
>> Thread-OPs?
>
> Suche einfach nach den Postings von Stefan Kanthak. Im wesentlichen geht
> es hierum: Message-ID:
><4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
Das Problem ist, dass ich von Stefans "Safer"-Zeugs nichts halte.
>> Thread-OPs?
>
> Suche einfach nach den Postings von Stefan Kanthak. Im wesentlichen geht
> es hierum: Message-ID:
><4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
Ich hatte mir das mal angesehen: viel zu restriktiv.
Dann kann ich alles auch gleich sein lassen.
So restriktiv ist noch nichtmal ein Linux.
Nein, das kann es nicht sein.
Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
Installationen einsetzt.
Uwe
Daniel Kohl
Jun 4, 2012, 1:52:42 PM6/4/12
to
Am 04.06.2012, 19:24 Uhr, schrieb Uwe Premer <m...@uwe-premer.de>:
>
> Das Problem ist, dass ich von Stefans "Safer"-Zeugs nichts halte.
> Ich hatte mir das mal angesehen: viel zu restriktiv.
> Dann kann ich alles auch gleich sein lassen.
> So restriktiv ist noch nichtmal ein Linux.
>
> Nein, das kann es nicht sein.
>
> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
> Installationen einsetzt.
>
> Uwe
Dann vielleicht besser den Gedanken dahinter verstehen und umsetzten,
>
> Das Problem ist, dass ich von Stefans "Safer"-Zeugs nichts halte.
> Ich hatte mir das mal angesehen: viel zu restriktiv.
> Dann kann ich alles auch gleich sein lassen.
> So restriktiv ist noch nichtmal ein Linux.
>
> Nein, das kann es nicht sein.
>
> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
> Installationen einsetzt.
>
> Uwe
sowie auf deinen Bedürfnisse anpassen.
Das ist ja das Übel, ohne Restriktionen wird es nicht sicherer. Jedwede
Sicherheit wird mit einem
Minus an Benutzerfreundlichkeit erkauft. Auf Knopfdruck, wie es die
AV-Firmen verkaufen wollen, geht
es nun mal nicht.
--
Daniel Kohl
Jun 4, 2012, 1:54:54 PM6/4/12
to
Gegen 99, irgenwas Prozent der alten Hüte!
--
Daniel Kohl
Jun 4, 2012, 2:07:05 PM6/4/12
to
Seit JAHREN(!!) *lach*
Die Besten, der Besten, der Besten, SIR!
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
Stefan Kanthak
Jun 4, 2012, 4:02:27 PM6/4/12
to
"Uwe Premer" <m...@uwe-premer.de> schrieb:
> Am Mon, 04 Jun 2012 18:12:15 +0200 schrieb Lars Gebauer:
>> * Uwe Premer:
>>> Am Mon, 04 Jun 2012 17:03:11 +0200 schrieb Lars Gebauer:
>>>> * Uwe Premer:
>>>>> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
> Ich hatte mir das mal angesehen: viel zu restriktiv.
Aha. Was an "Benutzer duerfen alle Anwendungen ausfuehren, die der
Administrator installiert hat" ist Dir zu restriktiv?
> Dann kann ich alles auch gleich sein lassen.
> So restriktiv ist noch nichtmal ein Linux.
Aber sicher ist es das: speichere doch mal mit dem Web-Browser eine
Datei in Dein $HOME und versuche dann, sie auszufuehren. MERKST DU WAS?
Oder nimm (D)einen Editor, schreibe ein Shell-Skript, speichere es in
$HOME und versuche es auszufuehren.
Unter UNIX bevorzuge ich allerdings "mount /home -o noexec"!
> Nein, das kann es nicht sein.
Doch, genau das ist es.
> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
> Installationen einsetzt.
BLOEDSINN! Oder soll ich Dich "Luegner" nennen?
SAFER wird hier seit 2006 auf JEDER XP-Installation ab Installations-
Medium aktiviert!
> Am Mon, 04 Jun 2012 18:12:15 +0200 schrieb Lars Gebauer:
>> * Uwe Premer:
>>> Am Mon, 04 Jun 2012 17:03:11 +0200 schrieb Lars Gebauer:
>>>> * Uwe Premer:
>>>>> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
>>>>> User-Account kaputt gemacht werden, was dann auch �rgerlich sein kann.
>>>>
>>>> War doch k�rzlich erst (wieder mal) (hier oder in einer der anderen
>>>> dcs.*-Gruppen) Thema. Auch dieses Risiko l��t sich eind�mmen.
>>>
>>> Interessant. Oder anders: w�rde mich interessieren.
>>>>
>>>> War doch k�rzlich erst (wieder mal) (hier oder in einer der anderen
>>>> dcs.*-Gruppen) Thema. Auch dieses Risiko l��t sich eind�mmen.
>>>
>>> Hast du oder sonst Jemand mal die entsprechenden MIDs zu den jeweiligen
>>> Thread-OPs?
>>
>> Suche einfach nach den Postings von Stefan Kanthak. Im wesentlichen geht
>> es hierum: Message-ID:
>><4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
>
> Das Problem ist, dass ich von Stefans "Safer"-Zeugs nichts halte.
Dein Problem!
>>> Thread-OPs?
>>
>> Suche einfach nach den Postings von Stefan Kanthak. Im wesentlichen geht
>> es hierum: Message-ID:
>><4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
>
> Das Problem ist, dass ich von Stefans "Safer"-Zeugs nichts halte.
> Ich hatte mir das mal angesehen: viel zu restriktiv.
Administrator installiert hat" ist Dir zu restriktiv?
> Dann kann ich alles auch gleich sein lassen.
> So restriktiv ist noch nichtmal ein Linux.
Datei in Dein $HOME und versuche dann, sie auszufuehren. MERKST DU WAS?
Oder nimm (D)einen Editor, schreibe ein Shell-Skript, speichere es in
$HOME und versuche es auszufuehren.
Unter UNIX bevorzuge ich allerdings "mount /home -o noexec"!
> Nein, das kann es nicht sein.
> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
> Installationen einsetzt.
SAFER wird hier seit 2006 auf JEDER XP-Installation ab Installations-
Medium aktiviert!
Uwe Premer
Jun 4, 2012, 5:26:34 PM6/4/12
to
Stefan Kanthak schrieb am 04.06.2012 22:02 Uhr:
> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>
>> Am Mon, 04 Jun 2012 18:12:15 +0200 schrieb Lars Gebauer:
>>> * Uwe Premer:
>>>> Am Mon, 04 Jun 2012 17:03:11 +0200 schrieb Lars Gebauer:
>>>>> * Uwe Premer:
>>>>>> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>
>> Am Mon, 04 Jun 2012 18:12:15 +0200 schrieb Lars Gebauer:
>>> * Uwe Premer:
>>>> Am Mon, 04 Jun 2012 17:03:11 +0200 schrieb Lars Gebauer:
>>>>> * Uwe Premer:
>>>>>> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
>>>>>> User-Account kaputt gemacht werden, was dann auch ärgerlich sein kann.
>>>>>
>>>>> War doch kürzlich erst (wieder mal) (hier oder in einer der anderen
>>>>> dcs.*-Gruppen) Thema. Auch dieses Risiko läßt sich eindämmen.
>>>>
>>>> Interessant. Oder anders: würde mich interessieren.
>>>>>
>>>>> War doch kürzlich erst (wieder mal) (hier oder in einer der anderen
>>>>> dcs.*-Gruppen) Thema. Auch dieses Risiko läßt sich eindämmen.
>>>>
>>>> Hast du oder sonst Jemand mal die entsprechenden MIDs zu den jeweiligen
>>>> Thread-OPs?
>>>
>>> Suche einfach nach den Postings von Stefan Kanthak. Im wesentlichen geht
>>> es hierum: Message-ID:
>>><4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
>>
>> Das Problem ist, dass ich von Stefans "Safer"-Zeugs nichts halte.
>
> Dein Problem!
Natürlich.
>>>> Thread-OPs?
>>>
>>> Suche einfach nach den Postings von Stefan Kanthak. Im wesentlichen geht
>>> es hierum: Message-ID:
>>><4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
>>
>> Das Problem ist, dass ich von Stefans "Safer"-Zeugs nichts halte.
>
> Dein Problem!
>> Ich hatte mir das mal angesehen: viel zu restriktiv.
>
> Aha. Was an "Benutzer duerfen alle Anwendungen ausfuehren, die der
> Administrator installiert hat" ist Dir zu restriktiv?
>> Dann kann ich alles auch gleich sein lassen.
>> So restriktiv ist noch nichtmal ein Linux.
>
> Aber sicher ist es das: speichere doch mal mit dem Web-Browser eine
> Datei in Dein $HOME und versuche dann, sie auszufuehren. MERKST DU WAS?
> Oder nimm (D)einen Editor, schreibe ein Shell-Skript, speichere es in
> $HOME und versuche es auszufuehren.
mir) gewollt.
> Unter UNIX bevorzuge ich allerdings "mount /home -o noexec"!
>> Nein, das kann es nicht sein.
>
> Doch, genau das ist es.
Stunden laufen.
>> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
>> Installationen einsetzt.
>
> BLOEDSINN! Oder soll ich Dich "Luegner" nennen?
schreibst du, ich zitiere:
| Siehe u.a. <http://home.arcor.de/skanthak/download/XP_FIXIT.INF> und
| <http://home.arcor.de/skanthak/download/XP_SAFER.INF>, die etwa 30%
| der Einstellungen meiner Installationen ausmachen.
Gut, ich gebe zu, dass 1/3 etwas "ungenau" ist, sagen wir also korrekt
"30%".
> SAFER wird hier seit 2006 auf JEDER XP-Installation ab Installations-
> Medium aktiviert!
Hier wurde noch nie das installiert.
Infektionen unter Win XP Pro, Vista und Win 7: exakt Null
Unter den Linuxen und Mac OS X ebenso.
Bedarf also für mich an "SAFER": null.
Uwe
Lars Gebauer
Jun 5, 2012, 3:04:14 AM6/5/12
to
* Uwe Premer:
>>> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
>>> Installationen einsetzt.
>>
>> BLOEDSINN! Oder soll ich Dich "Luegner" nennen?
>
> In deinem Posting <4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
> schreibst du, ich zitiere:
>
> | Siehe u.a. <http://home.arcor.de/skanthak/download/XP_FIXIT.INF> und
> | <http://home.arcor.de/skanthak/download/XP_SAFER.INF>, die etwa 30%
> | der Einstellungen meiner Installationen ausmachen.
>
> Gut, ich gebe zu, dass 1/3 etwas "ungenau" ist, sagen wir also korrekt
> "30%".
Weder. Noch.
>> SAFER wird hier seit 2006 auf JEDER XP-Installation ab Installations-
>> Medium aktiviert!
>
> Na prima.
> Hier wurde noch nie das installiert.
> Infektionen unter Win XP Pro, Vista und Win 7: exakt Null
>
> Unter den Linuxen und Mac OS X ebenso.
>
> Bedarf also f�r mich an "SAFER": null.
Ob Du Bedarf daran hast ist mir, ehrlich gesagt, v�llig Wumpe. Aber
Deine Logik solltest Du trotzdem in die General�berholung geben.
>>> Ich hatte mir das mal angesehen: viel zu restriktiv.
>>
>> Aha. Was an "Benutzer duerfen alle Anwendungen ausfuehren, die der
>> Administrator installiert hat" ist Dir zu restriktiv?
>
> Genau das.
Wie bitte?! Kannst Du das n�her erl�utern?
>>
>> Aha. Was an "Benutzer duerfen alle Anwendungen ausfuehren, die der
>> Administrator installiert hat" ist Dir zu restriktiv?
>
> Genau das.
>>> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
>>> Installationen einsetzt.
>>
>> BLOEDSINN! Oder soll ich Dich "Luegner" nennen?
>
> In deinem Posting <4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
> schreibst du, ich zitiere:
>
> | Siehe u.a. <http://home.arcor.de/skanthak/download/XP_FIXIT.INF> und
> | <http://home.arcor.de/skanthak/download/XP_SAFER.INF>, die etwa 30%
> | der Einstellungen meiner Installationen ausmachen.
>
> Gut, ich gebe zu, dass 1/3 etwas "ungenau" ist, sagen wir also korrekt
> "30%".
>> SAFER wird hier seit 2006 auf JEDER XP-Installation ab Installations-
>> Medium aktiviert!
>
> Na prima.
> Hier wurde noch nie das installiert.
> Infektionen unter Win XP Pro, Vista und Win 7: exakt Null
>
> Unter den Linuxen und Mac OS X ebenso.
>
Ob Du Bedarf daran hast ist mir, ehrlich gesagt, v�llig Wumpe. Aber
Deine Logik solltest Du trotzdem in die General�berholung geben.
Stefan Kanthak
Jun 5, 2012, 12:20:42 PM6/5/12
to
"Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
[ Software Restriction Policies ]
>>> Ich hatte mir das mal angesehen: viel zu restriktiv.
>>
>> Aha. Was an "Benutzer duerfen alle Anwendungen ausfuehren, die der
>> Administrator installiert hat" ist Dir zu restriktiv?
>
> Genau das.
Du solltest LANGSAM mal anfangen, ueber Rechtetrennung (und "Benutzer"-
Rollen) in "modernen" Betruebssystemen nachzudenken!
>>> Dann kann ich alles auch gleich sein lassen.
>>> So restriktiv ist noch nichtmal ein Linux.
>>
>> Aber sicher ist es das: speichere doch mal mit dem Web-Browser eine
>> Datei in Dein $HOME und versuche dann, sie auszufuehren. MERKST DU WAS?
>> Oder nimm (D)einen Editor, schreibe ein Shell-Skript, speichere es in
>> $HOME und versuche es auszufuehren.
>
> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so (von
> mir) gewollt.
MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
Dein Linux wird KEINE der Dateien ausfuehren!
UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111 NICHT!
[...]
>>> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
>>> Installationen einsetzt.
>>
>> BLOEDSINN! Oder soll ich Dich "Luegner" nennen?
>
> In deinem Posting <4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
> schreibst du, ich zitiere:
>
> | Siehe u.a. <http://home.arcor.de/skanthak/download/XP_FIXIT.INF> und
> | <http://home.arcor.de/skanthak/download/XP_SAFER.INF>, die etwa 30%
> | der Einstellungen meiner Installationen ausmachen. ~~~
~~~~~~~~~~~~~~~~~
lassen!
Damit auch Du es kapierst: 70% der EINSTELLUNGEN, die alle meine
Installationen bekommen, stehen NICHT in diesen beiden Skripts!
100% meiner Installationen bekommen 100% meiner Einstellungen!
[ Software Restriction Policies ]
>>> Ich hatte mir das mal angesehen: viel zu restriktiv.
>>
>> Aha. Was an "Benutzer duerfen alle Anwendungen ausfuehren, die der
>> Administrator installiert hat" ist Dir zu restriktiv?
>
> Genau das.
Rollen) in "modernen" Betruebssystemen nachzudenken!
>>> Dann kann ich alles auch gleich sein lassen.
>>> So restriktiv ist noch nichtmal ein Linux.
>>
>> Aber sicher ist es das: speichere doch mal mit dem Web-Browser eine
>> Datei in Dein $HOME und versuche dann, sie auszufuehren. MERKST DU WAS?
>> Oder nimm (D)einen Editor, schreibe ein Shell-Skript, speichere es in
>> $HOME und versuche es auszufuehren.
>
> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so (von
> mir) gewollt.
Dein Linux wird KEINE der Dateien ausfuehren!
UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111 NICHT!
[...]
>>> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
>>> Installationen einsetzt.
>>
>> BLOEDSINN! Oder soll ich Dich "Luegner" nennen?
>
> In deinem Posting <4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
> schreibst du, ich zitiere:
>
> | Siehe u.a. <http://home.arcor.de/skanthak/download/XP_FIXIT.INF> und
> | <http://home.arcor.de/skanthak/download/XP_SAFER.INF>, die etwa 30%
~~~~~~~~~~~~~~~~~
> Gut, ich gebe zu, dass 1/3 etwas "ungenau" ist, sagen wir also korrekt
> "30%".
Du solltest Deine Lese- und Verstaendnisschwaeche WIRKLICH behandeln
> "30%".
lassen!
Damit auch Du es kapierst: 70% der EINSTELLUNGEN, die alle meine
Installationen bekommen, stehen NICHT in diesen beiden Skripts!
100% meiner Installationen bekommen 100% meiner Einstellungen!
Helmut Hullen
Jun 5, 2012, 1:19:00 PM6/5/12
to
Hallo, Stefan,
Du meintest am 05.06.12:
>>> Aber sicher ist es das: speichere doch mal mit dem Web-Browser eine
>>> Datei in Dein $HOME und versuche dann, sie auszufuehren. MERKST DU
>>> WAS? Oder nimm (D)einen Editor, schreibe ein Shell-Skript,
>>> speichere es in $HOME und versuche es auszufuehren.
>>
>> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so
>> (von mir) gewollt.
> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
> Dein Linux wird KEINE der Dateien ausfuehren!
> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111
> NICHT!
Auch wenn Du recht laut schreist: Du irrst.
Um Stefan Kanthak zu zitieren: "MERKBEFREIT?! Oder einfach nur komplett
ahnungslos?"
Hilfsweise:
sh $script
oder
bash $script
funktioniert recht gut, bei passenden Skripts.
Ähnlich auch bei anderen Programmiersprachen.
Viele Gruesse!
Helmut
Du meintest am 05.06.12:
>>> Aber sicher ist es das: speichere doch mal mit dem Web-Browser eine
>>> Datei in Dein $HOME und versuche dann, sie auszufuehren. MERKST DU
>>> WAS? Oder nimm (D)einen Editor, schreibe ein Shell-Skript,
>>> speichere es in $HOME und versuche es auszufuehren.
>>
>> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so
>> (von mir) gewollt.
> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
> Dein Linux wird KEINE der Dateien ausfuehren!
> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111
> NICHT!
Um Stefan Kanthak zu zitieren: "MERKBEFREIT?! Oder einfach nur komplett
ahnungslos?"
Hilfsweise:
sh $script
oder
bash $script
funktioniert recht gut, bei passenden Skripts.
Ähnlich auch bei anderen Programmiersprachen.
Viele Gruesse!
Helmut
Uwe Premer
Jun 5, 2012, 5:27:43 PM6/5/12
to
Stefan Kanthak schrieb am 05.06.2012 18:20 Uhr:
> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
> Dein Linux wird KEINE der Dateien ausfuehren!
> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111 NICHT!
Ich kompiliere recht oft Source direkt im Home-Verzeichnis.
Das dadurch generierte File ist sofort und ohne Umwege ausführbar und
zwar im Quellverzeichnis, welches im Home liegt.
Und das mit
./configure
und
make
und zwar ohne sudo und ohne jeglichen Rootrechten.
Nach dem make kann ich das Kompilat sofort ausführen mittels
./File
Uwe
> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so (von
>> mir) gewollt.
>
> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
Du vll. selbst.
>> mir) gewollt.
>
> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
> Dein Linux wird KEINE der Dateien ausfuehren!
> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111 NICHT!
Das dadurch generierte File ist sofort und ohne Umwege ausführbar und
zwar im Quellverzeichnis, welches im Home liegt.
Und das mit
./configure
und
make
und zwar ohne sudo und ohne jeglichen Rootrechten.
Nach dem make kann ich das Kompilat sofort ausführen mittels
./File
Uwe
Stefan Kanthak
Jun 5, 2012, 5:41:59 PM6/5/12
to
"Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
> Stefan Kanthak schrieb am 05.06.2012 18:20 Uhr:
>> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>>> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so (von
>>> mir) gewollt.
>>
>> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
>
> Du vll. selbst.
>
>> Dein Linux wird KEINE der Dateien ausfuehren!
>> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111 NICHT!
>
> Ich kompiliere recht oft Source direkt im Home-Verzeichnis.
> Das dadurch generierte File ist sofort und ohne Umwege ausführbar
Falsch!
Probiers mal direkt mit "cc" und einem simplen "Hello world!"
> und zwar im Quellverzeichnis, welches im Home liegt.
> Und das mit
> ./configure
> und
> make
Und sowas nennst Du "direkt"?
> und zwar ohne sudo und ohne jeglichen Rootrechten.
> Nach dem make kann ich das Kompilat sofort ausführen mittels
> ./File
Sieh Dir das Makefile an, Dummerchen!
Dort wirst Du ein "chmod +x ./File" finden (mindestens beim Target
install:, das Du in Deiner grenzenlosen Unwissenheit unterschlagen
hast).
JFTR: meine *_SAFER.INF sind fuer ONU, nicht fuer Softwareentwickler.
Letzteren traue ich durchaus zu, die SAFER-Regeln so anzupassen, dass
sie selbsterstellte Software aufrufen koennen. Wenn ein Entwickler DAS
nicht kann, dann soll er besser keine Software entwickeln oder aendern.
> Stefan Kanthak schrieb am 05.06.2012 18:20 Uhr:
>> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>>> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so (von
>>> mir) gewollt.
>>
>> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
>
> Du vll. selbst.
>
>> Dein Linux wird KEINE der Dateien ausfuehren!
>> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111 NICHT!
>
> Ich kompiliere recht oft Source direkt im Home-Verzeichnis.
> Das dadurch generierte File ist sofort und ohne Umwege ausführbar
Probiers mal direkt mit "cc" und einem simplen "Hello world!"
> und zwar im Quellverzeichnis, welches im Home liegt.
> Und das mit
> ./configure
> und
> make
> und zwar ohne sudo und ohne jeglichen Rootrechten.
> Nach dem make kann ich das Kompilat sofort ausführen mittels
> ./File
Dort wirst Du ein "chmod +x ./File" finden (mindestens beim Target
install:, das Du in Deiner grenzenlosen Unwissenheit unterschlagen
hast).
JFTR: meine *_SAFER.INF sind fuer ONU, nicht fuer Softwareentwickler.
Letzteren traue ich durchaus zu, die SAFER-Regeln so anzupassen, dass
sie selbsterstellte Software aufrufen koennen. Wenn ein Entwickler DAS
nicht kann, dann soll er besser keine Software entwickeln oder aendern.
Uwe Premer
Jun 5, 2012, 6:37:06 PM6/5/12
to
>> Und das mit
>> ./configure
>> und
>> make
>
> Und sowas nennst Du "direkt"?
Letztendlich ging es doch darum, dass es im Home laut deiner Definition
>> ./configure
>> und
>> make
>
> Und sowas nennst Du "direkt"?
nicht möglich sein darf, dass ausführbare Dateien ausgeführt werden dürfen.
Aber genau das will ich halt machen können/dürfen und zwar sowohl unter
Linux (aus obigen Gründen, um nicht gleich ein sudo make install machen
zu müssen, sondern erstmal das Ausführbare so zu testen) als auch aus
selbigen Gründen unter Windows.
Und da sind mir halt die SAFER-Regeln etwas "im Weg".
Uwe
Burkhard Ott
Jun 5, 2012, 6:37:51 PM6/5/12
to
On Tue, 05 Jun 2012 23:41:59 +0200, Stefan Kanthak wrote:
> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>
>> Stefan Kanthak schrieb am 05.06.2012 18:20 Uhr:
>>> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>>>> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so
>>>> (von mir) gewollt.
>>>
>>> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
>>
>> Du vll. selbst.
>>
>>> Dein Linux wird KEINE der Dateien ausfuehren! UNIX setzt dummerweise
>>> beim Anlegen von Dateien die Permissions 111 NICHT!
>>
>> Ich kompiliere recht oft Source direkt im Home-Verzeichnis. Das dadurch
>> generierte File ist sofort und ohne Umwege ausführbar
>
> Falsch!
> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
Klar gehts das.
> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>
>> Stefan Kanthak schrieb am 05.06.2012 18:20 Uhr:
>>> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>>>> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so
>>>> (von mir) gewollt.
>>>
>>> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
>>
>> Du vll. selbst.
>>
>>> Dein Linux wird KEINE der Dateien ausfuehren! UNIX setzt dummerweise
>>> beim Anlegen von Dateien die Permissions 111 NICHT!
>>
>> Ich kompiliere recht oft Source direkt im Home-Verzeichnis. Das dadurch
>> generierte File ist sofort und ohne Umwege ausführbar
>
> Falsch!
> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
>> und zwar im Quellverzeichnis, welches im Home liegt. Und das mit
>> ./configure
>> und
>> make
>
> Und sowas nennst Du "direkt"?
aufruft oder Du das eintippst ist relativ bummi. Solange Du deine umask
002 hast wird das binary immer 755 angelegt.
>> und zwar ohne sudo und ohne jeglichen Rootrechten. Nach dem make kann
>> ich das Kompilat sofort ausführen mittels ./File
>
> Sieh Dir das Makefile an, Dummerchen! Dort wirst Du ein "chmod +x
> ./File" finden (mindestens beim Target install:, das Du in Deiner
> grenzenlosen Unwissenheit unterschlagen hast).
cc -o fertig test.c
./fertig
geht doch!
ls -la
-rwxr-xr-x 6544 Jun 5 15:30 fertig
man umask
cheers
Juergen P. Meier
Jun 6, 2012, 12:41:18 AM6/6/12
to
Uwe Premer <m...@uwe-premer.de>:
>>
>> Einsicht ist der 1. Schritt zur Besserung?
>
> Keine Ahnung, ob die ein Einsehen haben.
In diesem speziellen Punkt scheint es Einsehen zu sein.
>>| nicht jedoch gegen spezielle Angriffe, die von Staaten mit nahezu
>>| unlimitierten Budgets ausgehen.
>>
>> Nicht das Budget ist das Problem, sondern die simple Tatsache, daￜ es
>> sich um Malware handelte, die sich hï¿œchst unauffï¿œllig verhielt.
>
> Die hï¿œtten durch ihr riesiges Budget die Mï¿œglichkeit, ihre Malware gegen
> alle auf dem Markt befindlichen AV-Programme ausfï¿œhrlich zu testen und
Da brauchts kein grosses Budget fuer.
Es ist aber nicht das Budget der Hersteller dieser Schadsoftware, die
den AV-Herstellern probleme bereiten - einige Schadprogramme lassen
sich z.B. funktional kaum mehr von diversen "guten" Programmen
unterscheiden (heuristiken versagen regelmaessig). Und alle
Schadsoftwaere, die nicht auf Massenverbreitung ausgelegt ist (also
alles, was zielgerichtet ist - ueblicherweise Industrie-Spionage oder
eben staatliche Spionage sowie Sabotage) umgeht ganz prinzpiell die
etablierten Mechanismen der AV-Hersteller zur Kenntnisnahme, Analyse,
Klassifizierung/Kategorisierung, Musterextraktion und aufnahme
derselben in die Virendatenbank - denen eben in der Regel nur (schlecht
programmierte) Massenverbreitungsschadprogramme in die virtuellen
Netze gehen.
Es zeugt hingegen fast schon von Inkompetenz und Dilletantismus bei
den staatlichen Schadcodeschreiberlingen (dem Anschein nach
insbesondere diejenigen, die fuer die "Cyberabwehr" der USA
arbeiten - siehe die Beispiele Stuxnet/fLAME) dass deren Produkte
ueberhaupt von AV-Herstellern beim Fischen im Trueben gefunden und
als Schadcode identifiziert werden konnten.
Man kann ruhig davon ausgehen, dass dies - wie ueberall auch - nur die
unruehmlichen Ausnahmen schlechter Qualitaet darstellen.
> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
> User-Account kaputt gemacht werden, was dann auch ï¿œrgerlich sein kann.
Fuer den User, ja. Fuer das System (und alle anderne User) hingegen nicht.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> Am Mon, 04 Jun 2012 14:26:09 +0200 schrieb Lars Gebauer:
>> * Uwe Premer:
>> * Uwe Premer:
>>> http://heise.de/-1589640
>>>
>>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>>> erstellt worden seien, dass AV-Software einfach ï¿œberrannt wï¿œrde.
>>>
>>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>>
>> Einsicht ist der 1. Schritt zur Besserung?
>
> Keine Ahnung, ob die ein Einsehen haben.
In diesem speziellen Punkt scheint es Einsehen zu sein.
>>| nicht jedoch gegen spezielle Angriffe, die von Staaten mit nahezu
>>| unlimitierten Budgets ausgehen.
>>
>> Nicht das Budget ist das Problem, sondern die simple Tatsache, daￜ es
>> sich um Malware handelte, die sich hï¿œchst unauffï¿œllig verhielt.
>
> Die hï¿œtten durch ihr riesiges Budget die Mï¿œglichkeit, ihre Malware gegen
> alle auf dem Markt befindlichen AV-Programme ausfï¿œhrlich zu testen und
> dann so zu optimieren, dass AV-Software chancenlos sei.
Aeh, das kann eigentlich jeder Malwareschreiber.
Da brauchts kein grosses Budget fuer.
Es ist aber nicht das Budget der Hersteller dieser Schadsoftware, die
den AV-Herstellern probleme bereiten - einige Schadprogramme lassen
sich z.B. funktional kaum mehr von diversen "guten" Programmen
unterscheiden (heuristiken versagen regelmaessig). Und alle
Schadsoftwaere, die nicht auf Massenverbreitung ausgelegt ist (also
alles, was zielgerichtet ist - ueblicherweise Industrie-Spionage oder
eben staatliche Spionage sowie Sabotage) umgeht ganz prinzpiell die
etablierten Mechanismen der AV-Hersteller zur Kenntnisnahme, Analyse,
Klassifizierung/Kategorisierung, Musterextraktion und aufnahme
derselben in die Virendatenbank - denen eben in der Regel nur (schlecht
programmierte) Massenverbreitungsschadprogramme in die virtuellen
Netze gehen.
Es zeugt hingegen fast schon von Inkompetenz und Dilletantismus bei
den staatlichen Schadcodeschreiberlingen (dem Anschein nach
insbesondere diejenigen, die fuer die "Cyberabwehr" der USA
arbeiten - siehe die Beispiele Stuxnet/fLAME) dass deren Produkte
ueberhaupt von AV-Herstellern beim Fischen im Trueben gefunden und
als Schadcode identifiziert werden konnten.
Man kann ruhig davon ausgehen, dass dies - wie ueberall auch - nur die
unruehmlichen Ausnahmen schlechter Qualitaet darstellen.
> Selbst, wenn man Admin-Zugriffe sperrt, kann trotzdem immer noch was am
Fuer den User, ja. Fuer das System (und alle anderne User) hingegen nicht.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen P. Meier
Jun 6, 2012, 12:53:28 AM6/6/12
to
Jens Hektor <hek...@rz.rwth-aachen.de>:
Erstaunlich an fLAME ist vielmehr, dass es aufgefallen ist.
Ok, das geschah erst viele Jahre nach der "Markteinfuehrung", aber
immerhin.
Da scheinen wohl auch blinde Huehner bei den AV-Herstellern zu arbeiten.
> Am 04.06.2012 14:26, schrieb Lars Gebauer:
>> Nicht das Budget ist das Problem, sondern die simple Tatsache, daￜ es
>> sich um Malware handelte, die sich hï¿œchst unauffï¿œllig verhielt.
>
> Nicht nur das, sie war auch noch gï¿œltig signiert.
>> Nicht das Budget ist das Problem, sondern die simple Tatsache, daￜ es
>> sich um Malware handelte, die sich hï¿œchst unauffï¿œllig verhielt.
>
Erstaunlich an fLAME ist vielmehr, dass es aufgefallen ist.
Ok, das geschah erst viele Jahre nach der "Markteinfuehrung", aber
immerhin.
Da scheinen wohl auch blinde Huehner bei den AV-Herstellern zu arbeiten.
Juergen P. Meier
Jun 6, 2012, 12:54:58 AM6/6/12
to
begin 1 followup to Uwe Premer <m...@uwe-premer.de>:
In welchem MAnagermagazin hast du denn diesen Unsinn gelesen?
Wenn das der Realitaet entsprechen wuerde, wuerde Qualitaetssoftware
nur noch aus Indien kommen.
YMMD,
Juergen
> Am Mon, 4 Jun 2012 15:26:04 +0200 schrieb Heinz-Mario Frï¿œhbeis:
>> "Uwe Premer"...
>>> http://heise.de/-1589640
>>>
>>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>>> erstellt worden seien, dass AV-Software einfach ï¿œberrannt wï¿œrde.
>> "Uwe Premer"...
>>> http://heise.de/-1589640
>>>
>>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>>
>> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
>> Nur weil einer Geld kann_ er sich Genie kaufen?
>
> Wenn du statt klammen 2 Programmierern gleich ein Team von 20 oder 50
> Programmierern an so eine Aufgabe setzen kannst, wird das Ergebnis weit
> effektiver.
Muahahaha haha ahahahaha ahhahha - ROFL
>> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
>> Nur weil einer Geld kann_ er sich Genie kaufen?
>
> Wenn du statt klammen 2 Programmierern gleich ein Team von 20 oder 50
> Programmierern an so eine Aufgabe setzen kannst, wird das Ergebnis weit
> effektiver.
In welchem MAnagermagazin hast du denn diesen Unsinn gelesen?
Wenn das der Realitaet entsprechen wuerde, wuerde Qualitaetssoftware
nur noch aus Indien kommen.
YMMD,
Juergen
Juergen P. Meier
Jun 6, 2012, 12:57:04 AM6/6/12
to
Ansgar -59cobalt- Wiechers <usene...@planetcobalt.net>:
Systemverzeichns schreibt, ein anders Programm startet, ein paar DLLs
nachlaedt, auf ein CIFS-Share zugreift, versucht Registry-KEys in HKLM
und HKCU zu veraendern, einen Netzwerksocket aufmacht und zwei drei
Netzwerverbindungen oeffnet (mittels IE Bibliothek um durch Proxies zu
kommen) von einem Programm unterscheiden, dass ein paar Dateien im
Systemverzeichns schreibt, ein anders Programm startet, ein paar DLLs
nachlaedt, auf ein CIFS-Share zugreift, versucht Registry-KEys in HKLM
und HKCU zu veraendern, einen Netzwerksocket aufmacht und zwei drei
Netzwerverbindungen oeffnet (mittels IE Bibliothek um durch Proxies zu
kommen) unterscheiden?
Vor dieser Aufgabe stehen die Heuristikprogramme der AV-Hersteller.
> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>>> Heise meint zudem, dass wohl langsam auch nicht-staatliche AV-Ersteller
>>> dermassen grosse Ressourcen zur Verfügung hätten, dass Entwicklungen von
>>> Viren möglich seien, die von den AV-Herstellern nicht mehr entgegnet
>>> werden könnten.
>>
>> Auch das ist falsch: Botnetz-Betreiber produzieren seit Jahren im Tages-
>> oder Stundenrhythmus neue Varianten ihrer Schaedlinge und unterlaufen
>> damit KONTINUIERLICH die (signaturbasierte) Erkennung.
>
> Und warum verhaltensbasierte Erkennung auch nicht so das Gelbe vom Ei
> ist, hat Avira ja gerade demonstriert.
Wie genau willst du bitteschoen ein Programm, dass ein paar Dateien im
>> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>>> Heise meint zudem, dass wohl langsam auch nicht-staatliche AV-Ersteller
>>> dermassen grosse Ressourcen zur Verfügung hätten, dass Entwicklungen von
>>> Viren möglich seien, die von den AV-Herstellern nicht mehr entgegnet
>>> werden könnten.
>>
>> Auch das ist falsch: Botnetz-Betreiber produzieren seit Jahren im Tages-
>> oder Stundenrhythmus neue Varianten ihrer Schaedlinge und unterlaufen
>> damit KONTINUIERLICH die (signaturbasierte) Erkennung.
>
> Und warum verhaltensbasierte Erkennung auch nicht so das Gelbe vom Ei
> ist, hat Avira ja gerade demonstriert.
Systemverzeichns schreibt, ein anders Programm startet, ein paar DLLs
nachlaedt, auf ein CIFS-Share zugreift, versucht Registry-KEys in HKLM
und HKCU zu veraendern, einen Netzwerksocket aufmacht und zwei drei
Netzwerverbindungen oeffnet (mittels IE Bibliothek um durch Proxies zu
kommen) von einem Programm unterscheiden, dass ein paar Dateien im
Systemverzeichns schreibt, ein anders Programm startet, ein paar DLLs
nachlaedt, auf ein CIFS-Share zugreift, versucht Registry-KEys in HKLM
und HKCU zu veraendern, einen Netzwerksocket aufmacht und zwei drei
Netzwerverbindungen oeffnet (mittels IE Bibliothek um durch Proxies zu
kommen) unterscheiden?
Vor dieser Aufgabe stehen die Heuristikprogramme der AV-Hersteller.
Helmut Hullen
Jun 6, 2012, 2:59:00 AM6/6/12
to
Hallo, Stefan,
Du meintest am 05.06.12:
Du meintest am 05.06.12:
>>> Dein Linux wird KEINE der Dateien ausfuehren!
>>> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111
>>> NICHT!
Ja und?
>>> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111
>>> NICHT!
>> Ich kompiliere recht oft Source direkt im Home-Verzeichnis.
> Falsch!
> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
cd
echo 'echo Hallo Welt!' > hallo.sh
bash hallo.sh
Willst Du partout darauf hinaus, dass die Datei als "ausf�hrbar" gef�hrt
werden muss?
Das Recht kann ich (rein technisch) jeder beliebigen Datei in meinem
Home-Verzeichnis geben.
Viele Gruesse!
Helmut
Daniel Kohl
Jun 6, 2012, 3:36:45 AM6/6/12
to
Am 06.06.2012, 06:53 Uhr, schrieb Juergen P. Meier <nospa...@jors.net>:
> Jens Hektor <hek...@rz.rwth-aachen.de>:
>> Am 04.06.2012 14:26, schrieb Lars Gebauer:
>>> Nicht das Budget ist das Problem, sondern die simple Tatsache, daß es
> Jens Hektor <hek...@rz.rwth-aachen.de>:
>> Am 04.06.2012 14:26, schrieb Lars Gebauer:
>>> sich um Malware handelte, die sich höchst unauffällig verhielt.
>>
>> Nicht nur das, sie war auch noch gültig signiert.
>
> Erstaunlich an fLAME ist vielmehr, dass es aufgefallen ist.
>
> Ok, das geschah erst viele Jahre nach der "Markteinfuehrung", aber
> immerhin.
>
> Da scheinen wohl auch blinde Huehner bei den AV-Herstellern zu arbeiten.
Noch erstaunlihcer ist, dass bereits seit 2010 Samples in den Datenbanken
> Erstaunlich an fLAME ist vielmehr, dass es aufgefallen ist.
>
> Ok, das geschah erst viele Jahre nach der "Markteinfuehrung", aber
> immerhin.
>
> Da scheinen wohl auch blinde Huehner bei den AV-Herstellern zu arbeiten.
von zB F-Secure
und wohl auch bei anderen Herstellern vor lagen, und es einfach niemanden
interessiert hat.
Das ganze TAM-TAM, inclusive Weltuntergangsscenario-Bullshit, was von
AV_Herstellern und der ITU nun
veranstaltet wird, errinnert mich an das Gelaber zu Anfangszeiten des
"Krieges gegen den Terror", als man Gründe brauchte, den Menschen ihre
Freiheiten und
Rechte einzuschränken.
Man darf gespannt sein!
--
Daniel Kohl
Jun 6, 2012, 3:40:50 AM6/6/12
to
Am 06.06.2012, 06:54 Uhr, schrieb Juergen P. Meier <nospa...@jors.net>:
> begin 1 followup to Uwe Premer <m...@uwe-premer.de>:
> begin 1 followup to Uwe Premer <m...@uwe-premer.de>:
>> Am Mon, 4 Jun 2012 15:26:04 +0200 schrieb Heinz-Mario Frühbeis:
>>> "Uwe Premer"...
>>>> http://heise.de/-1589640
>>>>
>>>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>>>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>>>> erstellt worden seien, dass AV-Software einfach überrannt würde.
>>> "Uwe Premer"...
>>>> http://heise.de/-1589640
>>>>
>>>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>>>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>>>
>>> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
>>> Nur weil einer Geld kann_ er sich Genie kaufen?
>>
>> Wenn du statt klammen 2 Programmierern gleich ein Team von 20 oder 50
>> Programmierern an so eine Aufgabe setzen kannst, wird das Ergebnis weit
>> effektiver.
>
> Muahahaha haha ahahahaha ahhahha - ROFL
>
> In welchem MAnagermagazin hast du denn diesen Unsinn gelesen?
>
> Wenn das der Realitaet entsprechen wuerde, wuerde Qualitaetssoftware
> nur noch aus Indien kommen.
>
> YMMD,
> Juergen
Diese Annahme basiert sicher auf der bekannten Aussage, dass auch Affen,
>>> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
>>> Nur weil einer Geld kann_ er sich Genie kaufen?
>>
>> Wenn du statt klammen 2 Programmierern gleich ein Team von 20 oder 50
>> Programmierern an so eine Aufgabe setzen kannst, wird das Ergebnis weit
>> effektiver.
>
> Muahahaha haha ahahahaha ahhahha - ROFL
>
> In welchem MAnagermagazin hast du denn diesen Unsinn gelesen?
>
> Wenn das der Realitaet entsprechen wuerde, wuerde Qualitaetssoftware
> nur noch aus Indien kommen.
>
> YMMD,
> Juergen
die man an Schreibmaschinen setzt,
irgendwann einen Bestseller schreiben. Es kommt nur drauf an, wie viele
Affen wie lange auf den Maschinen herum hacken!
--
Daniel Kohl
Jun 6, 2012, 3:50:08 AM6/6/12
to
Am 06.06.2012, 06:57 Uhr, schrieb Juergen P. Meier <nospa...@jors.net>:
> Ansgar -59cobalt- Wiechers <usene...@planetcobalt.net>:
>
> Wie genau willst du bitteschoen ein Programm, dass ein paar Dateien im
> Systemverzeichns schreibt, ein anders Programm startet, ein paar DLLs
> nachlaedt, auf ein CIFS-Share zugreift, versucht Registry-KEys in HKLM
> und HKCU zu veraendern, einen Netzwerksocket aufmacht und zwei drei
> Netzwerverbindungen oeffnet (mittels IE Bibliothek um durch Proxies zu
> kommen) von einem Programm unterscheiden, dass ein paar Dateien im
> Systemverzeichns schreibt, ein anders Programm startet, ein paar DLLs
> nachlaedt, auf ein CIFS-Share zugreift, versucht Registry-KEys in HKLM
> und HKCU zu veraendern, einen Netzwerksocket aufmacht und zwei drei
> Netzwerverbindungen oeffnet (mittels IE Bibliothek um durch Proxies zu
> kommen) unterscheiden?
>
> Vor dieser Aufgabe stehen die Heuristikprogramme der AV-Hersteller.
>
> Juergen
Heuristik != Verhaltensanalyse. Fällt mir oft auf, dass dies gleich
gesetzt wird, ist aber ein
himmelweiter Unterschied.
Aber dennoch, beides funktioniert nicht richtig. Verhaltenserkennung aus
dem genannten Grund und Heuristik,
weil Signaturähnlichkeiten einfach gegen getestet werden, bis sie nicht
mehr auslösen.
Von den AV-Herstellern kommen dazu ja weder Studien, noch klare Aussagen,
aber wenn man einigen Security-Blogs so glaubt,
dann liegt die Heuristik bei der Erkennung bei weit unter 30%, Tendenz
fallend, und die
Verhaltensanalyse soll sogar öfters False-Positves geben, als dass sie
ihren Job richtig tut.
Aber davon liest man nirgends, von den AV-Herstellern. Sondern nur, dass
99,999999 aller
Asbach-Uraltvieren aus irgendwelchen Uraltdatenbanken, die in der Praxis
zum Gro gar nich tmehr
vor kommen, erkannt werden.
--
/
> Ansgar -59cobalt- Wiechers <usene...@planetcobalt.net>:
>
> Wie genau willst du bitteschoen ein Programm, dass ein paar Dateien im
> Systemverzeichns schreibt, ein anders Programm startet, ein paar DLLs
> nachlaedt, auf ein CIFS-Share zugreift, versucht Registry-KEys in HKLM
> und HKCU zu veraendern, einen Netzwerksocket aufmacht und zwei drei
> Netzwerverbindungen oeffnet (mittels IE Bibliothek um durch Proxies zu
> kommen) von einem Programm unterscheiden, dass ein paar Dateien im
> Systemverzeichns schreibt, ein anders Programm startet, ein paar DLLs
> nachlaedt, auf ein CIFS-Share zugreift, versucht Registry-KEys in HKLM
> und HKCU zu veraendern, einen Netzwerksocket aufmacht und zwei drei
> Netzwerverbindungen oeffnet (mittels IE Bibliothek um durch Proxies zu
> kommen) unterscheiden?
>
> Vor dieser Aufgabe stehen die Heuristikprogramme der AV-Hersteller.
>
> Juergen
gesetzt wird, ist aber ein
himmelweiter Unterschied.
Aber dennoch, beides funktioniert nicht richtig. Verhaltenserkennung aus
dem genannten Grund und Heuristik,
weil Signaturähnlichkeiten einfach gegen getestet werden, bis sie nicht
mehr auslösen.
Von den AV-Herstellern kommen dazu ja weder Studien, noch klare Aussagen,
aber wenn man einigen Security-Blogs so glaubt,
dann liegt die Heuristik bei der Erkennung bei weit unter 30%, Tendenz
fallend, und die
Verhaltensanalyse soll sogar öfters False-Positves geben, als dass sie
ihren Job richtig tut.
Aber davon liest man nirgends, von den AV-Herstellern. Sondern nur, dass
99,999999 aller
Asbach-Uraltvieren aus irgendwelchen Uraltdatenbanken, die in der Praxis
zum Gro gar nich tmehr
vor kommen, erkannt werden.
--
/
Juergen Ilse
Jun 6, 2012, 5:09:03 AM6/6/12
to
Hallo,
Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>> Stefan Kanthak schrieb am 04.06.2012 22:02 Uhr:
>>> "Uwe Premer" <m...@uwe-premer.de> schrieb:
> [ Software Restriction Policies ]
>>>> Ich hatte mir das mal angesehen: viel zu restriktiv.
>>> Aha. Was an "Benutzer duerfen alle Anwendungen ausfuehren, die der
>>> Administrator installiert hat" ist Dir zu restriktiv?
>> Genau das.
> Du solltest LANGSAM mal anfangen, ueber Rechtetrennung (und "Benutzer"-
> Rollen) in "modernen" Betruebssystemen nachzudenken!
Waere zu empfehlen ...
>>>> Dann kann ich alles auch gleich sein lassen.
>>>> So restriktiv ist noch nichtmal ein Linux.
>>> Aber sicher ist es das: speichere doch mal mit dem Web-Browser eine
>>> Datei in Dein $HOME und versuche dann, sie auszufuehren. MERKST DU WAS?
>>> Oder nimm (D)einen Editor, schreibe ein Shell-Skript, speichere es in
>>> $HOME und versuche es auszufuehren.
>> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so (von
>> mir) gewollt.
> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
> Dein Linux wird KEINE der Dateien ausfuehren!
> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111 NICHT!
Das ist so nicht korrekt. Beim anlegen von Dateien unter Linux werden
genau die Permissions gesetzt, die das Programm dass die Datei anlegt
dafuer bestimmt (ein Editor wird kein execute setzen, der Linker beim
anlegen eines executable Files dagegen schon). Die einzige Ausnahme von
dieser Regel ist, dass die vom Programm "gewuenschten" Rechte noch mit
der "umask" des Benutzers verknuepft wird (alle Bits, die in der umask
gesetzt sind, werden in den Dateirechten neu anzulegender Dateien aus-
geblendet).
> [...]
>>>> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
>>>> Installationen einsetzt.
>>> BLOEDSINN! Oder soll ich Dich "Luegner" nennen?
>> In deinem Posting <4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
>> schreibst du, ich zitiere:
>> | Siehe u.a. <http://home.arcor.de/skanthak/download/XP_FIXIT.INF> und
>> | <http://home.arcor.de/skanthak/download/XP_SAFER.INF>, die etwa 30%
>> | der Einstellungen meiner Installationen ausmachen. ~~~
> ~~~~~~~~~~~~~~~~~
>> Gut, ich gebe zu, dass 1/3 etwas "ungenau" ist, sagen wir also korrekt
>> "30%".
> Du solltest Deine Lese- und Verstaendnisschwaeche WIRKLICH behandeln
> lassen!
> Damit auch Du es kapierst: 70% der EINSTELLUNGEN, die alle meine
> Installationen bekommen, stehen NICHT in diesen beiden Skripts!
> 100% meiner Installationen bekommen 100% meiner Einstellungen!
So hatte ich das auch verstanden ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>> Stefan Kanthak schrieb am 04.06.2012 22:02 Uhr:
>>> "Uwe Premer" <m...@uwe-premer.de> schrieb:
> [ Software Restriction Policies ]
>>>> Ich hatte mir das mal angesehen: viel zu restriktiv.
>>> Aha. Was an "Benutzer duerfen alle Anwendungen ausfuehren, die der
>>> Administrator installiert hat" ist Dir zu restriktiv?
>> Genau das.
> Du solltest LANGSAM mal anfangen, ueber Rechtetrennung (und "Benutzer"-
> Rollen) in "modernen" Betruebssystemen nachzudenken!
>>>> Dann kann ich alles auch gleich sein lassen.
>>>> So restriktiv ist noch nichtmal ein Linux.
>>> Aber sicher ist es das: speichere doch mal mit dem Web-Browser eine
>>> Datei in Dein $HOME und versuche dann, sie auszufuehren. MERKST DU WAS?
>>> Oder nimm (D)einen Editor, schreibe ein Shell-Skript, speichere es in
>>> $HOME und versuche es auszufuehren.
>> Ja und? Genau das kann ich auch bei meinen Linuxen und das ist so (von
>> mir) gewollt.
> MERKBEFREIT?! Oder einfach nur komplett ahnungslos?
> Dein Linux wird KEINE der Dateien ausfuehren!
> UNIX setzt dummerweise beim Anlegen von Dateien die Permissions 111 NICHT!
genau die Permissions gesetzt, die das Programm dass die Datei anlegt
dafuer bestimmt (ein Editor wird kein execute setzen, der Linker beim
anlegen eines executable Files dagegen schon). Die einzige Ausnahme von
dieser Regel ist, dass die vom Programm "gewuenschten" Rechte noch mit
der "umask" des Benutzers verknuepft wird (alle Bits, die in der umask
gesetzt sind, werden in den Dateirechten neu anzulegender Dateien aus-
geblendet).
> [...]
>>>> Ausserdem sagt er dort selbst, dass er das Zeugs auch nur in 1/3 seiner
>>>> Installationen einsetzt.
>>> BLOEDSINN! Oder soll ich Dich "Luegner" nennen?
>> In deinem Posting <4fc7cbef$0$6559$9b4e...@newsspool4.arcor-online.net>
>> schreibst du, ich zitiere:
>> | Siehe u.a. <http://home.arcor.de/skanthak/download/XP_FIXIT.INF> und
>> | <http://home.arcor.de/skanthak/download/XP_SAFER.INF>, die etwa 30%
>> | der Einstellungen meiner Installationen ausmachen. ~~~
> ~~~~~~~~~~~~~~~~~
>> Gut, ich gebe zu, dass 1/3 etwas "ungenau" ist, sagen wir also korrekt
>> "30%".
> Du solltest Deine Lese- und Verstaendnisschwaeche WIRKLICH behandeln
> lassen!
> Damit auch Du es kapierst: 70% der EINSTELLUNGEN, die alle meine
> Installationen bekommen, stehen NICHT in diesen beiden Skripts!
> 100% meiner Installationen bekommen 100% meiner Einstellungen!
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Juergen Ilse
Jun 6, 2012, 5:26:24 AM6/6/12
to
Hallo,
Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
> "Uwe Premer" <m#TO...@uwe-premer.de> schrieb:
>> Ich kompiliere recht oft Source direkt im Home-Verzeichnis.
>> Das dadurch generierte File ist sofort und ohne Umwege ausfï¿œhrbar
> Falsch!
Ich vermute, dass er in seiner umask nicht unbedingt alle Exec-Bits gesetzt
hat, folglich wird es bei ihm so wie von ihm genannt funktionieren.
> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
Ratgeber, in diesem Fall liegst du aber wirklich daneben ...
----------------
iilse@ubuntu:~$ ls -l bla.out
ls: Zugriff auf bla.out nicht mï¿œglich: Datei oder Verzeichnis nicht gefunden
ilse@ubuntu:~$ echo 'int main(){return 0;}' | gcc -o bla.out -x c -
ilse@ubuntu:~$ ls -l bla.out
-rwxrwxr-x 1 ilse ilse 7115 Jun 6 11:14 bla.out
ilse@ubuntu:~$ umask
0002
ilse@ubuntu:~$
----------------
Ich habe mir erlaubt, den "printf" Aufruf wegzulassen, aber das aendert ja
nichts an den Dateirechten der Ausgabedatei (ja, ich weiss, dass auf diesem
Rechner die umask sehr "freizuegig" gesetzt ist, aber das ist in diesem
Fall ausnahmsweise mal Absicht) ...
>> und zwar im Quellverzeichnis, welches im Home liegt.
>> Und das mit
>> ./configure
>> und
>> make
durch den Aufruf des Compilers erzeugt wird (und der Compileraufruf laeuft
dann genauso wie von mir oben angegeben, nur durch restriktiveres setzen
der umask bekommt man den Compiler dahin, dass fuer den output des von ihm
aufgerufenen Linkers keine execute-Rechte gesetzt werden ...).
>> und zwar ohne sudo und ohne jeglichen Rootrechten.
und du Schreibrechte (und execute-Rechte) in dem Verzeichnis hast, in dem
die Datei liegt, hast du beim klassischen unix-Rechte-System auch das
Recht, die Dateirechte jener Datei zu aendern, selbst dann, wenn du vorher
keinerlei Rechte auf die Datei hattest.
>> Nach dem make kann ich das Kompilat sofort ausfï¿œhren mittels
>> ./File
> Sieh Dir das Makefile an, Dummerchen!
> Dort wirst Du ein "chmod +x ./File" finden (mindestens beim Target
> install:, das Du in Deiner grenzenlosen Unwissenheit unterschlagen
> hast).
In meinem oben zitierten Compileraufruf ist keinerlei "chmod" im Spiel.
> Sieh Dir das Makefile an, Dummerchen!
> Dort wirst Du ein "chmod +x ./File" finden (mindestens beim Target
> install:, das Du in Deiner grenzenlosen Unwissenheit unterschlagen
> hast).
Juergen Ilse
Jun 6, 2012, 5:29:18 AM6/6/12
to
Hallo,
Burkhard Ott <news...@derith.de> wrote:
> Und? Hier spart man sich das tippen, ob nun das make file den compiler
> aufruft oder Du das eintippst ist relativ bummi. Solange Du deine umask
> 002 hast wird das binary immer 755 angelegt.
Auch wenn es sicherlich nur ein Fluechtigkeitsafehler war: Bei umask 002
werden die Dateirechte 775 werden, fuer 755 als Dateirechte muesste die
umask auf 022 stehen ...
Burkhard Ott <news...@derith.de> wrote:
> Und? Hier spart man sich das tippen, ob nun das make file den compiler
> aufruft oder Du das eintippst ist relativ bummi. Solange Du deine umask
> 002 hast wird das binary immer 755 angelegt.
werden die Dateirechte 775 werden, fuer 755 als Dateirechte muesste die
umask auf 022 stehen ...
Juergen Ilse
Jun 6, 2012, 5:32:08 AM6/6/12
to
Hallo,
Helmut Hullen <Hel...@hullen.de> wrote:
> Probier doch mal
> cd
>
> echo 'echo Hallo Welt!' > hallo.sh
> bash hallo.sh
Halt doch mal bitte deine voellig andere Baustelle aus der Diskussion heraus.
Ode rhast du noch nicht einmal bemerkt, dass es sich um eine voellig andere
Baustelle handelt?
> Willst Du partout darauf hinaus, dass die Datei als "ausführbar" geführt
> werden muss?
Darauf (und auf das ausfuehren von binaries, nicht von shell-scripten,
wollte er hinaus, ja).
Helmut Hullen <Hel...@hullen.de> wrote:
> Probier doch mal
> cd
>
> echo 'echo Hallo Welt!' > hallo.sh
> bash hallo.sh
Ode rhast du noch nicht einmal bemerkt, dass es sich um eine voellig andere
Baustelle handelt?
> Willst Du partout darauf hinaus, dass die Datei als "ausführbar" geführt
> werden muss?
Darauf (und auf das ausfuehren von binaries, nicht von shell-scripten,
wollte er hinaus, ja).
Juergen Ilse
Jun 6, 2012, 5:41:26 AM6/6/12
to
Hallo,
Daniel Kohl <cons...@hotmail.de> wrote:
> Heuristik != Verhaltensanalyse. Fï¿œllt mir oft auf, dass dies gleich
genannten Gruenden), Heuristik aber nicht unbedingt immer Verhaltensanalyse
(man kann auch Heuristiken bei der Erkennung von "Virenpattern" einsetzen,
was allerdings die Wahrscheinlichkeit von Fehlalarmen deutlich erhoehen
duerfte ...).
> Von den AV-Herstellern kommen dazu ja weder Studien, noch klare Aussagen,
> aber wenn man einigen Security-Blogs so glaubt,
> dann liegt die Heuristik bei der Erkennung bei weit unter 30%, Tendenz
> fallend, und die
> Verhaltensanalyse soll sogar ï¿œfters False-Positves geben, als dass sie
> ihren Job richtig tut.
Wundert dich das? Mich nicht.
> Aber davon liest man nirgends, von den AV-Herstellern. Sondern nur, dass
> 99,999999 aller
> Asbach-Uraltvieren aus irgendwelchen Uraltdatenbanken, die in der Praxis
> zum Gro gar nich tmehr
> vor kommen, erkannt werden.
Viele davon kommen sogar noch vor, koennen aber oftmals einem aktuell
gehaltenen System mit einem *denkenden* Nutzer gar nichts mehr anhaben ...
Es gibt aber noch viele "ungepatchte Systeme" und "unvorsichtige Nutzer".
Selbst Swen und Sasser soll man noch reichlich in der freien Wildbahn finden.
Daniel Kohl <cons...@hotmail.de> wrote:
> Heuristik != Verhaltensanalyse. Fï¿œllt mir oft auf, dass dies gleich
> gesetzt wird, ist aber ein
> himmelweiter Unterschied.
Verhaltensanalyse ist eigentlich *immer* auch Heuristik (aus den von Juergen
> himmelweiter Unterschied.
genannten Gruenden), Heuristik aber nicht unbedingt immer Verhaltensanalyse
(man kann auch Heuristiken bei der Erkennung von "Virenpattern" einsetzen,
was allerdings die Wahrscheinlichkeit von Fehlalarmen deutlich erhoehen
duerfte ...).
> Von den AV-Herstellern kommen dazu ja weder Studien, noch klare Aussagen,
> aber wenn man einigen Security-Blogs so glaubt,
> dann liegt die Heuristik bei der Erkennung bei weit unter 30%, Tendenz
> fallend, und die
> ihren Job richtig tut.
Wundert dich das? Mich nicht.
> Aber davon liest man nirgends, von den AV-Herstellern. Sondern nur, dass
> 99,999999 aller
> Asbach-Uraltvieren aus irgendwelchen Uraltdatenbanken, die in der Praxis
> zum Gro gar nich tmehr
> vor kommen, erkannt werden.
gehaltenen System mit einem *denkenden* Nutzer gar nichts mehr anhaben ...
Es gibt aber noch viele "ungepatchte Systeme" und "unvorsichtige Nutzer".
Selbst Swen und Sasser soll man noch reichlich in der freien Wildbahn finden.
Uwe Premer
Jun 6, 2012, 6:55:23 AM6/6/12
to
Juergen P. Meier schrieb am 06.06.2012 06:54 Uhr:
> begin 1 followup to Uwe Premer <m...@uwe-premer.de>:
> begin 1 followup to Uwe Premer <m...@uwe-premer.de>:
>> Am Mon, 4 Jun 2012 15:26:04 +0200 schrieb Heinz-Mario Fr�hbeis:
>>> "Uwe Premer"...
>>>> http://heise.de/-1589640
>>>>
>>>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>>>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>>>> erstellt worden seien, dass AV-Software einfach �berrannt w�rde.
>>> "Uwe Premer"...
>>>> http://heise.de/-1589640
>>>>
>>>> Die AV-Hersteller seien so ziemlich machtlos gegen staatlich
>>>> hergestellte Schadsoftware, weil diese mit dermassen riesigen Budgets
>>>
>>> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
>>> Nur weil einer Geld kann_ er sich Genie kaufen?
>>
>> Wenn du statt klammen 2 Programmierern gleich ein Team von 20 oder 50
>> Programmierern an so eine Aufgabe setzen kannst, wird das Ergebnis weit
>> effektiver.
>
> Muahahaha haha ahahahaha ahhahha - ROFL
>
> In welchem MAnagermagazin hast du denn diesen Unsinn gelesen?
>
> Wenn das der Realitaet entsprechen wuerde, wuerde Qualitaetssoftware
> nur noch aus Indien kommen.
Er hier z.B. hat sich wissenschaftlich intensiv damit auseinandergesetzt:
>>> Was in aller Welt hat denn immer das Geld mit Genie zu tun?
>>> Nur weil einer Geld kann_ er sich Genie kaufen?
>>
>> Wenn du statt klammen 2 Programmierern gleich ein Team von 20 oder 50
>> Programmierern an so eine Aufgabe setzen kannst, wird das Ergebnis weit
>> effektiver.
>
> Muahahaha haha ahahahaha ahhahha - ROFL
>
> In welchem MAnagermagazin hast du denn diesen Unsinn gelesen?
>
> Wenn das der Realitaet entsprechen wuerde, wuerde Qualitaetssoftware
> nur noch aus Indien kommen.
<subs.emis.de/LNI/Proceedings/Proceedings105/gi-proc-105-020.pdf>
Uwe
Daniel Kohl
Jun 6, 2012, 6:57:08 AM6/6/12
to
In der Antivirerei ist die Heuristik nichts andres als die Prüfung auf
Signaturähnlichkeiten,
das wars dann auch schon. Sicher haben Programme,
die sich ähnlich verhalten oft auch ähnliche Signaturen, aber das muss
nicht sein, wie du schon sagst.
Virusprogrammierer lachen sich jedenfalls auf einschlägigen Boards schlapp
darüber.
Verhaltensanalyse prüft das logische Verhalten der Software und soll
"verdächtiges Benehmen melden"
Meiner Meinung nach ist das schon "kaputt by Design", denn es ist nicht
das Verhalten, was einen Virus
von einem gewollten Programm unterscheidet, sondern ob der User dieses
Verhalten WÜNSCHT!
Alles nur noch mehr Schlangenöl!
Signaturähnlichkeiten,
das wars dann auch schon. Sicher haben Programme,
die sich ähnlich verhalten oft auch ähnliche Signaturen, aber das muss
nicht sein, wie du schon sagst.
Virusprogrammierer lachen sich jedenfalls auf einschlägigen Boards schlapp
darüber.
Verhaltensanalyse prüft das logische Verhalten der Software und soll
"verdächtiges Benehmen melden"
Meiner Meinung nach ist das schon "kaputt by Design", denn es ist nicht
das Verhalten, was einen Virus
von einem gewollten Programm unterscheidet, sondern ob der User dieses
Verhalten WÜNSCHT!
Alles nur noch mehr Schlangenöl!
Juergen Ilse
Jun 6, 2012, 7:13:37 AM6/6/12
to
> In der Antivirerei ist die Heuristik nichts andres als die Prüfung auf
> Signaturähnlichkeiten, das wars dann auch schon.
Das was die Hersteller solcher Software so bezeichnen, ist nur das von dir
> Signaturähnlichkeiten, das wars dann auch schon.
erwaehnte. Das aendert aber nichts an der Tatsache, dass die bei der Ver-
haltensanalyse verwendeten Methoden letztlich auch auf Heuristik (im eigent-
lichen Sinn, nicht in dem Sinne, wie die Hersteller solcher Software den
Begriff verwenden) beruhen. Das wollte ich mit meinem Posting ausdruecken.
Eigentloich bezeichnet naemlich der Begriff Heuristik eher "mehr oder weniger
qualifiziertes raten", nicht mehr ...
Helmut Hullen
Jun 6, 2012, 7:51:00 AM6/6/12
to
Hallo, Juergen,
Du meintest am 06.06.12:
>> Willst Du partout darauf hinaus, dass die Datei als "ausf�hrbar"
>> gef�hrt werden muss?
> Darauf (und auf das ausfuehren von binaries, nicht von
> shell-scripten, wollte er hinaus, ja).
Aha - eine Sonder-Baustelle. Sch�n, dass Du erkl�rst, was Stefan meint
(und zu schreiben vers�umt).
Viele Gruesse!
Helmut
Du meintest am 06.06.12:
>> Willst Du partout darauf hinaus, dass die Datei als "ausf�hrbar"
>> gef�hrt werden muss?
> Darauf (und auf das ausfuehren von binaries, nicht von
> shell-scripten, wollte er hinaus, ja).
(und zu schreiben vers�umt).
Viele Gruesse!
Helmut
Helmut Hullen
Jun 6, 2012, 7:54:00 AM6/6/12
to
Hallo, Daniel,
Du meintest am 06.06.12:
> Verhaltensanalyse pr�ft das logische Verhalten der Software und soll
> "verd�chtiges Benehmen melden"
Mag sein.
Ich unterstelle einfach mal, dass Du keinen Virenscanner benutzt. Wie
stellst Du fest, ob sich ein Virus in Dein System eingenistet hat?
Viele Gruesse!
Helmut
Du meintest am 06.06.12:
> Verhaltensanalyse pr�ft das logische Verhalten der Software und soll
> "verd�chtiges Benehmen melden"
Mag sein.
Ich unterstelle einfach mal, dass Du keinen Virenscanner benutzt. Wie
stellst Du fest, ob sich ein Virus in Dein System eingenistet hat?
Viele Gruesse!
Helmut
Lars Gebauer
Jun 6, 2012, 8:53:29 AM6/6/12
to
* Uwe Premer:
| JFTR: meine *_SAFER.INF sind fuer ONU, nicht fuer Softwareentwickler.
| Letzteren traue ich durchaus zu, die SAFER-Regeln so anzupassen, dass
| sie selbsterstellte Software aufrufen koennen. Wenn ein Entwickler DAS
| nicht kann, dann soll er besser keine Software entwickeln oder
| aendern.
Warum hast Du das nicht mitzitiert bzw. gehst nicht darauf ein?
> Letztendlich ging es doch darum, dass es im Home laut deiner Definition
> nicht möglich sein darf, dass ausführbare Dateien ausgeführt werden dürfen.
> Aber genau das will ich halt machen können/dürfen und zwar sowohl unter
> Linux (aus obigen Gründen, um nicht gleich ein sudo make install machen
> zu müssen, sondern erstmal das Ausführbare so zu testen) als auch aus
> selbigen Gründen unter Windows.
>
> Und da sind mir halt die SAFER-Regeln etwas "im Weg".
Stefan schrieb (wahrscheinlich nicht ohne Grund);
> nicht möglich sein darf, dass ausführbare Dateien ausgeführt werden dürfen.
> Aber genau das will ich halt machen können/dürfen und zwar sowohl unter
> Linux (aus obigen Gründen, um nicht gleich ein sudo make install machen
> zu müssen, sondern erstmal das Ausführbare so zu testen) als auch aus
> selbigen Gründen unter Windows.
>
> Und da sind mir halt die SAFER-Regeln etwas "im Weg".
| JFTR: meine *_SAFER.INF sind fuer ONU, nicht fuer Softwareentwickler.
| Letzteren traue ich durchaus zu, die SAFER-Regeln so anzupassen, dass
| sie selbsterstellte Software aufrufen koennen. Wenn ein Entwickler DAS
| nicht kann, dann soll er besser keine Software entwickeln oder
| aendern.
Ansgar -59cobalt- Wiechers
Jun 6, 2012, 9:24:36 AM6/6/12
to
Uwe Premer <m#TO...@uwe-premer.de> wrote:
> Er hier z.B. hat sich wissenschaftlich intensiv damit auseinandergesetzt:
> <subs.emis.de/LNI/Proceedings/Proceedings105/gi-proc-105-020.pdf>
Wo genau in diesem Paper glaubst du die Aussage erkennen zu können,
> Er hier z.B. hat sich wissenschaftlich intensiv damit auseinandergesetzt:
> <subs.emis.de/LNI/Proceedings/Proceedings105/gi-proc-105-020.pdf>
Software-Entwicklung würde mit der Anzahl der Entwickler prima(tm) in
die Breite skalieren?
cu
59cobalt
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
Uwe Premer
Jun 6, 2012, 9:23:35 AM6/6/12
to
In <4fcf52db$0$9520$9b4e...@newsspool1.arcor-online.net> schrieb Lars:
> * Uwe Premer:
Uwe
> * Uwe Premer:
>> Und da sind mir halt die SAFER-Regeln etwas "im Weg".
>
> Stefan schrieb (wahrscheinlich nicht ohne Grund);
>
> | JFTR: meine *_SAFER.INF sind fuer ONU, nicht fuer Softwareentwickler.
> | Letzteren traue ich durchaus zu, die SAFER-Regeln so anzupassen, dass
> | sie selbsterstellte Software aufrufen koennen. Wenn ein Entwickler DAS
> | nicht kann, dann soll er besser keine Software entwickeln oder
> | aendern.
>
> Warum hast Du das nicht mitzitiert bzw. gehst nicht darauf ein?
Weil ich halt kein Software-Entwickler bin.
>
> Stefan schrieb (wahrscheinlich nicht ohne Grund);
>
> | JFTR: meine *_SAFER.INF sind fuer ONU, nicht fuer Softwareentwickler.
> | Letzteren traue ich durchaus zu, die SAFER-Regeln so anzupassen, dass
> | sie selbsterstellte Software aufrufen koennen. Wenn ein Entwickler DAS
> | nicht kann, dann soll er besser keine Software entwickeln oder
> | aendern.
>
> Warum hast Du das nicht mitzitiert bzw. gehst nicht darauf ein?
Uwe
Daniel Kohl
Jun 6, 2012, 9:31:49 AM6/6/12
to
Am 06.06.2012, 13:54 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
> Hallo, Daniel,
>
> Du meintest am 06.06.12:
>
>> Verhaltensanalyse prüft das logische Verhalten der Software und soll
> Hallo, Daniel,
>
> Du meintest am 06.06.12:
>
>> "verdächtiges Benehmen melden"
>
> Mag sein.
> Ich unterstelle einfach mal, dass Du keinen Virenscanner benutzt. Wie
> stellst Du fest, ob sich ein Virus in Dein System eingenistet hat?
>
> Viele Gruesse!
> Helmut
>
Gegenfrage: Und du als AV-Benutzer, wie erkennst du ihn? Und sag jetzt
> Mag sein.
> Ich unterstelle einfach mal, dass Du keinen Virenscanner benutzt. Wie
> stellst Du fest, ob sich ein Virus in Dein System eingenistet hat?
>
> Viele Gruesse!
> Helmut
>
nicht "aber mein AV"!
Das sagt dir in der Regel eben nicht, das sich ein Virus eingeschlichen
hat.
Wie werden denn die meisten "Superviren" erkannt? Doch nicht durch
AV-Software, sondern durch ihre Aktivität!
Sind sie einmal bekannt, brauch ich auch bloß kein AV, denn dann weis ich
wie sie arbeiten und passe mein Sicherheitskonzept ggf. an.
Da unterstellst du teilweise richtig. In meinem Sicherheitskonzept haben
Virenscanner durchaus ihren Platz.
Jedoch nicht zum Schutz und nicht auf dem System, sondern als Live DVD.
Ich nutze ganz gerne Desinfect der CT,
da diese eh abonniert ist. Jedoch setze ich diese 4 Scanengines weder zum
Schutz ein, noch installiere ich irgendwas.
Der Trick bei mir besteht darin, dass ich wirksam verhindere, dass sich
überhaupt ein Virsu "einschleichen" kann.
Konsequentes Softwarewhitelisting, striktes Multiuserprinzip und damit
verbundene NTFS Berechtigungen und
du verhinderst, dass überhaupt ein Virus auf dem PC ausgeführt werden kann.
Ich habe meinetwegen 10 Programme, die erlaubt sind, die ich pflegen und
hegen muss, >>deren Verhalten ich kenne<<.
Das ist besser als der Wettlauf, hunderttausende unbekannte Programme
blacklisten zu wollen. Zu denen täglich hunderte,
wenn nicht tausende, dazu kommen. Ein Wettlauf, den man nicht gewinnen
kann. Und dafür diese unvollständige Liste für einen pflegen zu lassen,
bezahlt man dann möglicherweise auch noch Geld!
Zusätzlich nutze ich noch eine Spielerei wie EMET, die bestimmte gezielte
Angriffsszenarien etwas erschwert.
Sicherlich bleiben IMMER die Möglichkeiten von ganz gezielten Angriffen
auf ein ganz bestimmtes System.
Aber selbst da behaupte ich, mache ich es dem Angreifer schwerer, als
würde ich einfach nur Schlangenöl-Software installieren
und hoffen, dass sie mich schützt.
Wovor mein Sicherheitskonzept nicht schützt, schützt dich auch kein
AV-Programm. Von daher stellt sich die Frage nach dem Erkennen nicht.
Natürlich ist mir bewusst, dass (beispielsweise) eine vertrauenswürdige
Installationsquelle kompromitiert sein könnte.
Dass es immer die Möglichkeit gibt, ein Sicherheitskonzept zu umgehen, und
sei sie noch so komplex, aber es gibt sie meist.
Daher nutze ich ganz gerne, als kleinen Teil des Konzeptes, einen
Offlinescanner wie Desinfect.
Jedoch nicht als Schutzmechanismus!
Einfach um auch die sehr geringe Eventualität einer Kompromittierung
mindestens auf Schlangölbasis zu erkennen,
ohne durch die Installation weitere Sicherheitslücken aufzureißen, oder
mir das virenhafte, schädliche Verhalten von
"Live-Guards" antun zu müssen. Eher nach dem Motto: Naja, schaden tut es
so ja auch nichts, als dass ich wirklich vom
Sinn überzeugt wäre.
Gebraucht habe ich es auf den von mir konfigurierten Geräten in all den
Jahren genau NULL mal.
Uwe Premer
Jun 6, 2012, 9:56:53 AM6/6/12
to
Ansgar -59cobalt- Wiechers schrieb am 06.06.2012 15:24 Uhr:
> Uwe Premer <m#TO...@uwe-premer.de> wrote:
>> Er hier z.B. hat sich wissenschaftlich intensiv damit auseinandergesetzt:
>> <subs.emis.de/LNI/Proceedings/Proceedings105/gi-proc-105-020.pdf>
>
> Wo genau in diesem Paper glaubst du die Aussage erkennen zu können,
> Software-Entwicklung würde mit der Anzahl der Entwickler prima(tm) in
> die Breite skalieren?
Dann halt anders:
> Uwe Premer <m#TO...@uwe-premer.de> wrote:
>> Er hier z.B. hat sich wissenschaftlich intensiv damit auseinandergesetzt:
>> <subs.emis.de/LNI/Proceedings/Proceedings105/gi-proc-105-020.pdf>
>
> Wo genau in diesem Paper glaubst du die Aussage erkennen zu können,
> Software-Entwicklung würde mit der Anzahl der Entwickler prima(tm) in
> die Breite skalieren?
wenn z.B. bei den Linux-Distributoren Entwickler fehlen, ziehen sich
neue Versionen in Länge.
Es ist einfach so, wenn zuwenig Fachleute vorhanden sind, kann halt
Vieles nicht in der gewünschten Zeit vollendet werden, und das ist bei
Software genauso wie im Handwerk.
Für mich an der Stelle dann EOD, weil weitere Diskussionen über das
Topic nix mehr bringen,
Uwe
Juergen P. Meier
Jun 6, 2012, 11:06:22 AM6/6/12
to
Uwe Premer <m#TO...@uwe-premer.de>:
kompliziertes wie ein Betriebsystem - das genuegend viele Modular
verschiedene Komponenten enthaelt, damit das in eine bestimmte Breite
skaliert.
Wer hingegen mit Verstand gesegnet ist, versteht, dass eine nicht
teilbare Aufgabe nicht mit der Anzahl der Aufgabenloeser skalieren
*KANN*.
Oder um deinen Handwerksvergleich zu verwenden: Die Aufgabe, mehrere
Gewinde in eine Spindel zu drehen kannst du gerne mal versuchen auf
mehrere Drehbaenke zu verteilen, in der Hoffnung, dass die schneller
und effizienter arbeiten.
> Ansgar -59cobalt- Wiechers schrieb am 06.06.2012 15:24 Uhr:
>> Uwe Premer <m#TO...@uwe-premer.de> wrote:
>>> Er hier z.B. hat sich wissenschaftlich intensiv damit auseinandergesetzt:
>>> <subs.emis.de/LNI/Proceedings/Proceedings105/gi-proc-105-020.pdf>
>>
>> Wo genau in diesem Paper glaubst du die Aussage erkennen zu können,
>> Software-Entwicklung würde mit der Anzahl der Entwickler prima(tm) in
>> die Breite skalieren?
>
> Dann halt anders:
> wenn z.B. bei den Linux-Distributoren Entwickler fehlen, ziehen sich
> neue Versionen in Länge.
> Es ist einfach so, wenn zuwenig Fachleute vorhanden sind, kann halt
> Vieles nicht in der gewünschten Zeit vollendet werden, und das ist bei
> Software genauso wie im Handwerk.
Es ging um *EINE* Funktionalitaet. Du hingegen beziehst dich auf sowas
>> Uwe Premer <m#TO...@uwe-premer.de> wrote:
>>> Er hier z.B. hat sich wissenschaftlich intensiv damit auseinandergesetzt:
>>> <subs.emis.de/LNI/Proceedings/Proceedings105/gi-proc-105-020.pdf>
>>
>> Wo genau in diesem Paper glaubst du die Aussage erkennen zu können,
>> Software-Entwicklung würde mit der Anzahl der Entwickler prima(tm) in
>> die Breite skalieren?
>
> Dann halt anders:
> wenn z.B. bei den Linux-Distributoren Entwickler fehlen, ziehen sich
> neue Versionen in Länge.
> Es ist einfach so, wenn zuwenig Fachleute vorhanden sind, kann halt
> Vieles nicht in der gewünschten Zeit vollendet werden, und das ist bei
> Software genauso wie im Handwerk.
kompliziertes wie ein Betriebsystem - das genuegend viele Modular
verschiedene Komponenten enthaelt, damit das in eine bestimmte Breite
skaliert.
Wer hingegen mit Verstand gesegnet ist, versteht, dass eine nicht
teilbare Aufgabe nicht mit der Anzahl der Aufgabenloeser skalieren
*KANN*.
Oder um deinen Handwerksvergleich zu verwenden: Die Aufgabe, mehrere
Gewinde in eine Spindel zu drehen kannst du gerne mal versuchen auf
mehrere Drehbaenke zu verteilen, in der Hoffnung, dass die schneller
und effizienter arbeiten.
Juergen P. Meier
Jun 6, 2012, 11:14:45 AM6/6/12
to
Daniel Kohl <cons...@hotmail.de>:
> In der Antivirerei ist die Heuristik nichts andres als die Prï¿œfung auf
> Signaturï¿œhnlichkeiten,
> darï¿œber.
Das, was vollmundig als Verhaltensanalyse verkauft wird, ist nichts
weiter als die syntaktische Zerlegung in Funktionen (quasi eine
teilweise de-compilierung) und eine heuristische Analyse des
so ermittelten statischen Funktionsbaumes eines stueck unbekannten Codes.
Und zwar heuristisch nach aehnlichkeiten zu bekannt "boesen" Progamm-
logikteilen.
> Verhaltensanalyse prï¿œft das logische Verhalten der Software und soll
> "verdï¿œchtiges Benehmen melden"
Echte verhaltensanalyse bedingt eine Ausfuehrung der potentiellen
Schadsoftware in einer Systemsimulation, das kostet Zeit und
Ressourcen, die man auf dem Desktop nunmal prinzipiell nicht hat -
wenn man konkurenzfaehig sein will.
Also verkauft man lieber erseters unter falschem Namen.
> Meiner Meinung nach ist das schon "kaputt by Design", denn es ist nicht
> das Verhalten, was einen Virus
> von einem gewollten Programm unterscheidet, sondern ob der User dieses
> Verhalten Wï¿œNSCHT!
Und das kommt auch noch hinzu.
> Alles nur noch mehr Schlangenï¿œl!
Ach.
> In der Antivirerei ist die Heuristik nichts andres als die Prï¿œfung auf
> Signaturï¿œhnlichkeiten,
> das wars dann auch schon. Sicher haben Programme,
> die sich ï¿œhnlich verhalten oft auch ï¿œhnliche Signaturen, aber das muss
> nicht sein, wie du schon sagst.
> Virusprogrammierer lachen sich jedenfalls auf einschlï¿œgigen Boards schlapp
> darï¿œber.
Das, was vollmundig als Verhaltensanalyse verkauft wird, ist nichts
weiter als die syntaktische Zerlegung in Funktionen (quasi eine
teilweise de-compilierung) und eine heuristische Analyse des
so ermittelten statischen Funktionsbaumes eines stueck unbekannten Codes.
Und zwar heuristisch nach aehnlichkeiten zu bekannt "boesen" Progamm-
logikteilen.
> Verhaltensanalyse prï¿œft das logische Verhalten der Software und soll
> "verdï¿œchtiges Benehmen melden"
Echte verhaltensanalyse bedingt eine Ausfuehrung der potentiellen
Schadsoftware in einer Systemsimulation, das kostet Zeit und
Ressourcen, die man auf dem Desktop nunmal prinzipiell nicht hat -
wenn man konkurenzfaehig sein will.
Also verkauft man lieber erseters unter falschem Namen.
> Meiner Meinung nach ist das schon "kaputt by Design", denn es ist nicht
> das Verhalten, was einen Virus
> von einem gewollten Programm unterscheidet, sondern ob der User dieses
Und das kommt auch noch hinzu.
> Alles nur noch mehr Schlangenï¿œl!
Ach.
Helmut Hullen
Jun 6, 2012, 11:17:00 AM6/6/12
to
Hallo, Daniel,
Du meintest am 06.06.12:
>>> Verhaltensanalyse pr�ft das logische Verhalten der Software und
Du meintest am 06.06.12:
>>> soll "verd�chtiges Benehmen melden"
>> Mag sein.
>> Ich unterstelle einfach mal, dass Du keinen Virenscanner benutzt.
>> Wie stellst Du fest, ob sich ein Virus in Dein System eingenistet
>> hat?
> Gegenfrage: Und du als AV-Benutzer, wie erkennst du ihn? Und sag
> jetzt nicht "aber mein AV"!
Was mir bisher zugeschickt wurde, das hatte entweder schon mein E-Mail-
> jetzt nicht "aber mein AV"!
Provider oder aber mein eigener Filter vorsortiert. Und dann reichte
fast immer ein Blick auf den Absender.
Zu Sasser-Zeiten reichte ein Blick auf die Dateigr�sse und auf die Menge
der (Schrott-)Pakete.
Beim Albaner-Virus reicht ein Blick auf den Inhalt.
Bei "root kits" (auf der Linux-Seite) verlasse ich mich weitgehend auf
meine Scanner.
Zusammengefasst: "das kommt drauf an!"
> Das sagt dir in der Regel eben nicht, das sich ein Virus
> eingeschlichen hat.
> Wie werden denn die meisten "Superviren" erkannt? Doch nicht durch
Mag sein - so etwas scheint bei meinen Rechnern noch nicht eingebaut zu
sein. Mache ich was falsch?
> Sind sie einmal bekannt, brauch ich auch blo� kein AV, denn dann weis
> ich wie sie arbeiten und passe mein Sicherheitskonzept ggf. an.
Du willst hier doch nicht etwa offen eingestehen, dass auch Dein
Sicherheitskonzept keinen 100-prozentigen Schutz liefert?
> Da unterstellst du teilweise richtig. In meinem Sicherheitskonzept
> haben Virenscanner durchaus ihren Platz.
> Jedoch nicht zum Schutz und nicht auf dem System, sondern als Live
> DVD. Ich nutze ganz gerne Desinfect der CT,
> da diese eh abonniert ist. Jedoch setze ich diese 4 Scanengines weder
> zum Schutz ein, noch installiere ich irgendwas.
CD ist es mir zu unhandlich. Aber jeder nach seinen F�higkeiten ...
> Der Trick bei mir besteht darin, dass ich wirksam verhindere, dass
Aha - also kommt bei Dir sowieso keine Schadsoftware auf den Rechner.
Dann m�sstest Du aber auch nicht mit einer Live-CD jonglieren.
> Konsequentes Softwarewhitelisting, striktes Multiuserprinzip und
> damit verbundene NTFS Berechtigungen und
> kann.
Aber dann h�tte er sich ja bereits eingeschlichen.
Auf einem meiner Rechner liegen inzwischen etwa 30 Virenpakete - die
richten keinen Schaden an.
> Wovor mein Sicherheitskonzept nicht sch�tzt, sch�tzt dich auch kein
> AV-Programm. Von daher stellt sich die Frage nach dem Erkennen nicht.
Doch.
Du betreibst viel manuellen Aufwand und weisst, dass Du keinen 100-
prozentigen Schutz hast.
Ich verlagere den gr�ssten Teil der Arbeit auf Automaten - reicht bei
meinen Rechnern. Und entlastet mich.
> Daher nutze ich ganz gerne, als kleinen Teil des Konzeptes, einen
> Offlinescanner wie Desinfect.
> Jedoch nicht als Schutzmechanismus!
> Gebraucht habe ich es auf den von mir konfigurierten Ger�ten in all
> den Jahren genau NULL mal.
Bei meinem Schutzsystem habe ich in den letzten etwa 20 Jahren keinen
Virenbefall gehabt ... ohne zus�tzlichen Arbeitsaufwand.
Viele Gruesse!
Helmut
Daniel Kohl
Jun 6, 2012, 12:40:32 PM6/6/12
to
Am 06.06.2012, 17:17 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
>
> Nein? Meine Virenscanner sagen das aber. Sollte ich sie ersetzen?
>
Ich begründe nun, wie viele sicher schon vor mir, nochmal, warum diese das
>
> Nein? Meine Virenscanner sagen das aber. Sollte ich sie ersetzen?
>
nicht tun KÖNNEN:
Das Konzept, welches du favorisierst, ist, erst mal alles jedem auf dem
Rechner zu erlauben.
Genauer: alle Programme ausführbar zu halten, vollkommen egal woher sie
stammen und was sie sind.
Und dann später das "böse Zeug" an Hand einer Liste zu verbieten.
Dadurch bedingt:
Zum Einen müssen hunderttausende (Schad)Programme geblacklistet werden,
die du eben dann als Ausnahme NICHT ausführen willst.
Du befindest dich also ständig in einem Wettlauf mit den
Virenprogrammierern,
den du niemals gewinnen kannst. Das liegt in der Natur der Sache.
Denn der Virus muss ja irgendwo schon einmal Schaden angerichtet haben, um
überhaupt zur
Analyse eingereicht zu werden.
Zum Anderen gibt es stets ein mehr oder minder großes Zeitfenster,
vom ersten Auftreten, bis zum Erscheinen auf der Blacklist. Also der
Signaturendatenbank.
Je nach dem, wie "gut" der Virus gemacht ist, können dies auch schonmal
Jahre sein,
wie das aktuelle Beispiel zeigt.
Heuristiken funktionieren nicht, da der Vergleich von Signaturen mit
bekannten Viren auf Abänderungen
und Ähnlichkeiten sehr leicht umgangen werden kann.
Verhaltensanalyse ist "kaputt by Design".
Ich behaupte, nein ich weiß es, dass jeder versierte 16 Jährige, der mit
einem Virenbaukasten umzugehen weiß,
dir innerhalb von einigen Stunden einen Virus auftischt, der weder von
deinem Virenprogramm erkannt wird,
noch auf irgendeiner Signaturdatenbank zu finden ist, solang du ihn nicht
als verdächtig einreichst.
Und selbst dann dauert es nochmal.
Jeder, der sich ernsthaft mit IT-Sicherheit befasst, wird dir sagen, dass
dein Konzept einfach fürn Popo
ist, wenn du in so einem Wettlauf gefangen bist und du Umdenken solltest.
Das betrifft jetzt nicht nur AV Programme,
sondern ist eine Grundlage.
>> Wie werden denn die meisten "Superviren" erkannt? Doch nicht durch
>
> Mag sein - so etwas scheint bei meinen Rechnern noch nicht eingebaut zu
> sein. Mache ich was falsch?
>
Okay, entschuldige, mit so viel Polemik hätte ich jetzt gar nicht
> Mag sein - so etwas scheint bei meinen Rechnern noch nicht eingebaut zu
> sein. Mache ich was falsch?
>
gerechnet.
Rhetorisch geschickter von mir wäre es gewesen, "Superviren" durch "neuen
Viren"
zu ersetzen.
Ich dachte aber, der Sinn erschließt sich und wird nicht absichtlich
falsch verstanden um
ihn dann,folglich auch falsch, auszuschlachten. Mein Fehler.
Aber um bei deinem kleinen polemischen Sticheleien zu bleiben:
Der "Schein" wird dich möglicherweise trügen, denn Schutz davor hast du
NULL.
>> Sind sie einmal bekannt, brauch ich auch bloß kein AV, denn dann weis
>> ich wie sie arbeiten und passe mein Sicherheitskonzept ggf. an.
>
> Du willst hier doch nicht etwa offen eingestehen, dass auch Dein
> Sicherheitskonzept keinen 100-prozentigen Schutz liefert?
>
Wer behauptet denn, er könne 100%igen Schutz liefern? Das wäre grober
>
> Du willst hier doch nicht etwa offen eingestehen, dass auch Dein
> Sicherheitskonzept keinen 100-prozentigen Schutz liefert?
>
Unfug von Grund auf.
Ich bin aber in der Lage, im Gegensatz zu AV-Programmen, mich ÜBERHAUPT zu
schützen.
>> Da unterstellst du teilweise richtig. In meinem Sicherheitskonzept
>> haben Virenscanner durchaus ihren Platz.
>> Jedoch nicht zum Schutz und nicht auf dem System, sondern als Live
>> DVD. Ich nutze ganz gerne Desinfect der CT,
>> da diese eh abonniert ist. Jedoch setze ich diese 4 Scanengines weder
>> zum Schutz ein, noch installiere ich irgendwas.
>
> CD ist es mir zu unhandlich. Aber jeder nach seinen Fähigkeiten ...
Verstehe ich jetzt nicht. Desinfect IST eine (Ubuntu)LiveCD- welche nur 4
AV Engines enthält.
Wo ganau ist da das Problem?
>> Der Trick bei mir besteht darin, dass ich wirksam verhindere, dass
>
> Aha - also kommt bei Dir sowieso keine Schadsoftware auf den Rechner.
> Dann müsstest Du aber auch nicht mit einer Live-CD jonglieren.
> Aha - also kommt bei Dir sowieso keine Schadsoftware auf den Rechner.
>
Bei mir kann in der keine Schadsoftware ausgeführt werden, nein.
Die Live CD dient nicht dem Schutz, sondern der Analyse.
>> Konsequentes Softwarewhitelisting, striktes Multiuserprinzip und
>> damit verbundene NTFS Berechtigungen und
>> kann.
>
> Aber dann hätte er sich ja bereits eingeschlichen.
> Auf einem meiner Rechner liegen inzwischen etwa 30 Virenpakete - die
> richten keinen Schaden an.
>
Wann sollte er sich bitte einschleichen? Das Systenm wird aufgesetzt und
> richten keinen Schaden an.
>
entsprechend Konfiguriert, ehe es
produktiv wird.
Auf meinen Rechnern befinden sich daher genau NULL
Virenpackete und richten somit ebenfalls keinen Schaden an.
>> Wovor mein Sicherheitskonzept nicht schützt, schützt dich auch kein
>> AV-Programm. Von daher stellt sich die Frage nach dem Erkennen nicht.
>
> Doch.
> Du betreibst viel manuellen Aufwand und weisst, dass Du keinen 100-
> prozentigen Schutz hast.
> Ich verlagere den grössten Teil der Arbeit auf Automaten - reicht bei
>
> Doch.
> Du betreibst viel manuellen Aufwand und weisst, dass Du keinen 100-
> prozentigen Schutz hast.
> meinen Rechnern. Und entlastet mich.
>
Und das ist eben ein Irrglaube und weit verbreiteter Mythos. Es gibt nun
>
mal keine Sicherheit auf Knopfdruck.
Es gibt ebensowenig Sicherheit, dadurch, dass man einmal etwas
konfiguriert und es dann in Ruhe lässt
und sich denkt "Nun bin ich ja sicher".
Nein, es ist vielmehr ein immerwährender Prozess und bedarf ständiger
Aufmerksamkeit.
Es müssen ständig Logs geprüft, Prozesse wie Installationen gründlich
geplant und durchgeführt
und somit ein gewisser Aufwand betrieben werden, wenn man auf Sicherheit
wirklich Wert legt.
Alles Andere ist Augenwischerei.
>> Daher nutze ich ganz gerne, als kleinen Teil des Konzeptes, einen
>> Offlinescanner wie Desinfect.
>> Jedoch nicht als Schutzmechanismus!
>
> [...]
>
>> den Jahren genau NULL mal.
>
> Bei meinem Schutzsystem habe ich in den letzten etwa 20 Jahren keinen
> Virenbefall gehabt ... ohne zusätzlichen Arbeitsaufwand.
>
> Bei meinem Schutzsystem habe ich in den letzten etwa 20 Jahren keinen
>
Du wirst es mir nachsehen, wenn es mir schwer fällt, das zu glauben.
Da du dich ja scheinbar alleine, oder wenigsten hauptsächlich,
auf deine Software verlässt, würde dir ein Befall wahrscheinlich nicht
auffallen, wenn dein AV nicht anschlägt.
Ansgar -59cobalt- Wiechers
Jun 6, 2012, 12:59:17 PM6/6/12
to
Uwe Premer <m#TO...@uwe-premer.de> wrote:
> Ansgar -59cobalt- Wiechers schrieb am 06.06.2012 15:24 Uhr:
>> Uwe Premer <m#TO...@uwe-premer.de> wrote:
>>> Er hier z.B. hat sich wissenschaftlich intensiv damit auseinandergesetzt:
>>> <subs.emis.de/LNI/Proceedings/Proceedings105/gi-proc-105-020.pdf>
>>
>> Wo genau in diesem Paper glaubst du die Aussage erkennen zu können,
>> Software-Entwicklung würde mit der Anzahl der Entwickler prima(tm) in
>> die Breite skalieren?
>
> Dann halt anders:
> wenn z.B. bei den Linux-Distributoren Entwickler fehlen, ziehen sich
> neue Versionen in Länge.
> Es ist einfach so, wenn zuwenig Fachleute vorhanden sind, kann halt
> Vieles nicht in der gewünschten Zeit vollendet werden, und das ist bei
> Software genauso wie im Handwerk.
*seufz*
> Ansgar -59cobalt- Wiechers schrieb am 06.06.2012 15:24 Uhr:
>> Uwe Premer <m#TO...@uwe-premer.de> wrote:
>>> Er hier z.B. hat sich wissenschaftlich intensiv damit auseinandergesetzt:
>>> <subs.emis.de/LNI/Proceedings/Proceedings105/gi-proc-105-020.pdf>
>>
>> Wo genau in diesem Paper glaubst du die Aussage erkennen zu können,
>> Software-Entwicklung würde mit der Anzahl der Entwickler prima(tm) in
>> die Breite skalieren?
>
> Dann halt anders:
> wenn z.B. bei den Linux-Distributoren Entwickler fehlen, ziehen sich
> neue Versionen in Länge.
> Es ist einfach so, wenn zuwenig Fachleute vorhanden sind, kann halt
> Vieles nicht in der gewünschten Zeit vollendet werden, und das ist bei
> Software genauso wie im Handwerk.
Nochmal: die Fachleute muss man a) erst mal finden, und b) kann man
danach Software-Projekte immer noch nicht beliebig in die Breite
skalieren. Im Gegensatz zum Handwerk läuft Software-Entwicklung nämlich
keineswegs so ab, dass der Architekt eine Zeichnung macht, und der
Entwickler das Werkstück dann einfach gemäß der Zeichnung anfertigt.
Muss dir nicht gefallen, ist aber trotzdem so.
Helmut Hullen
Jun 6, 2012, 1:16:00 PM6/6/12
to
Hallo, Daniel,
Du meintest am 06.06.12:
Du meintest am 06.06.12:
>> Nein? Meine Virenscanner sagen das aber. Sollte ich sie ersetzen?
> Ich begr�nde nun, wie viele sicher schon vor mir, nochmal, warum
> diese das nicht tun K�NNEN:
> Das Konzept, welches du favorisierst, ist, erst mal alles jedem auf
> dem Rechner zu erlauben.
Du gehst von einer falschen Annahme aus. Damit taugen die
Schlussfolgerungen nichts.
> Aber um bei deinem kleinen polemischen Sticheleien zu bleiben:
> du NULL.
Das gilt f�r jeden Schutzmechanismus, das gilt auch f�r Deine
Bestrebungen, Deinen Rechner zu sch�tzen.
> Wer behauptet denn, er k�nne 100%igen Schutz liefern? Das w�re grober
> Unfug von Grund auf.
> Ich bin aber in der Lage, im Gegensatz zu AV-Programmen, mich
> �BERHAUPT zu sch�tzen.
> Ich bin aber in der Lage, im Gegensatz zu AV-Programmen, mich
Auch Virenscanner k�nnen beim Schutz helfen. Genauso wie Deine
(mehreren) Teil-Verfahren.
>>> Ich nutze ganz gerne Desinfect der CT,
>> Live- CD ist es mir zu unhandlich. Aber jeder nach seinen
>> F�higkeiten ...
> Verstehe ich jetzt nicht. Desinfect IST eine (Ubuntu)LiveCD- welche
> Wo ganau ist da das Problem?
Kannst Du im zugeh�rigen Forum nachlesen. Da tauchen etliche Beitr�ge
auch von mir auf, die die Langzeit-Tauglichkeit usw. betreffen. Das
m�ssen wir nicht unbedingt hierhin kopieren.
[...]
> Wann sollte er sich bitte einschleichen? Das Systenm wird aufgesetzt
> und entsprechend Konfiguriert, ehe es
> produktiv wird.
> Auf meinen Rechnern befinden sich daher genau NULL
> Virenpackete und richten somit ebenfalls keinen Schaden an.
>> Ich verlagere den gr�ssten Teil der Arbeit auf Automaten - reicht
>> bei meinen Rechnern. Und entlastet mich.
>>
> Und das ist eben ein Irrglaube und weit verbreiteter Mythos. Es gibt
> nun mal keine Sicherheit auf Knopfdruck.
Habe ich nirgendwo behauptet, also musst Du nichts derartiges
>>
> Und das ist eben ein Irrglaube und weit verbreiteter Mythos. Es gibt
> nun mal keine Sicherheit auf Knopfdruck.
widerlegen.
> Es gibt ebensowenig Sicherheit, dadurch, dass man einmal etwas
> und sich denkt "Nun bin ich ja sicher".
Aha!
Wer sagte gerade eben "Auf meinen Rechnern befinden sich daher genau
NULL Virenpackete und richten somit ebenfalls keinen Schaden an."?
> Nein, es ist vielmehr ein immerw�hrender Prozess und bedarf st�ndiger
> Aufmerksamkeit.
> Es m�ssen st�ndig Logs gepr�ft, Prozesse wie Installationen gr�ndlich
> geplant und durchgef�hrt
> und somit ein gewisser Aufwand betrieben werden, wenn man auf
> Sicherheit wirklich Wert legt.
> Alles Andere ist Augenwischerei.
Eben - das kann ich mit wenig weiterem Aufwand haben - wie bei meinen
> Sicherheit wirklich Wert legt.
> Alles Andere ist Augenwischerei.
Rechnern seit etwa 20 Jahren - oder aber mit viel weiterem Aufwand.
Also bleibe ich bei meinen Verfahren.
>> Bei meinem Schutzsystem habe ich in den letzten etwa 20 Jahren
> Du wirst es mir nachsehen, wenn es mir schwer f�llt, das zu glauben.
Klar - f�llt unter Glaubensfreiheit.
> Da du dich ja scheinbar alleine, oder wenigsten haupts�chlich,
> auf deine Software verl�sst, w�rde dir ein Befall wahrscheinlich
> nicht auffallen, wenn dein AV nicht anschl�gt.
Du gehst schon wieder von falschen Annahmen aus.
Zudem: wenn mir nichts auff�llt, dann ist das kein Indiz daf�r, dass der
Rechner frei von Schad-Software ist.
Viele Gruesse!
Helmut
Daniel Kohl
Jun 6, 2012, 1:57:01 PM6/6/12
to
Am 06.06.2012, 19:16 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
> Hallo, Daniel,
>
> Du meintest am 06.06.12:
>
>>> Nein? Meine Virenscanner sagen das aber. Sollte ich sie ersetzen?
>
>> Ich begründe nun, wie viele sicher schon vor mir, nochmal, warum
> Hallo, Daniel,
>
> Du meintest am 06.06.12:
>
>>> Nein? Meine Virenscanner sagen das aber. Sollte ich sie ersetzen?
>
>> diese das nicht tun KÖNNEN:
>
>> Das Konzept, welches du favorisierst, ist, erst mal alles jedem auf
>> dem Rechner zu erlauben.
>
> Nein.
> Du gehst von einer falschen Annahme aus. Damit taugen die
> Schlussfolgerungen nichts.
>
Was ist Softwareblacklisteing, also ein Av denn dann, vom Prinzip her?
>> Das Konzept, welches du favorisierst, ist, erst mal alles jedem auf
>> dem Rechner zu erlauben.
>
> Nein.
> Du gehst von einer falschen Annahme aus. Damit taugen die
> Schlussfolgerungen nichts.
>
Alles zulassen und unerwünschtes Blacklisten,
Thats AV-Software.
Würdest du Whitelisting verwenden, bräuchtest du kein Blacklisting mehr.
Dein AV wäre schlich überflüssig.
Daher meine Schlussfolgerung.
Wie wäre es denn, wenn du dein Sicherheitskonzept einmal grob umrissen
vorstellst? Dass es auf Blacklisting beruht,
war für mich offensichtlich. Wenn ich also falsch gefolgert habe, dann
kläre mich doch bitte auf!
>> Aber um bei deinem kleinen polemischen Sticheleien zu bleiben:
>> du NULL.
>
> Das gilt für jeden Schutzmechanismus, das gilt auch für Deine
> Bestrebungen, Deinen Rechner zu schützen.
>
>> Wer behauptet denn, er könne 100%igen Schutz liefern? Das wäre grober
>> Unfug von Grund auf.
>> Ich bin aber in der Lage, im Gegensatz zu AV-Programmen, mich
>> ÜBERHAUPT zu schützen.
>> Ich bin aber in der Lage, im Gegensatz zu AV-Programmen, mich
>
> Auch Virenscanner können beim Schutz helfen. Genauso wie Deine
> (mehreren) Teil-Verfahren.
>
Eben nicht. Siehe die, nun wirklich ausführliche Beschreibung, warum nicht.
Ich mag mich da jetzt nicht ständig wiederholen.
Gehe doch bitte auf die sachlichen, von mir angeführten Argumente ein und
führe möglichst Beispiele an.
Ansonsten knallen wir uns doch nur Standpunkte an den Kopf. Das ist keine
gesunde Basis für eine
sinnvolle Diskussion.
Ich stimme dir so weit zu, dass es für jemdnen, der keine Ahnung und
keinen hat, der ihm hilft und
den er fragen kann, sowie keinerlei Interesse am Rechner zeigt, sich mit
aller Macht Cracks installieren will
und Keygens nutzt, möglicherweise besser ist, als nichts.
>
>> Wann sollte er sich bitte einschleichen? Das Systenm wird aufgesetzt
>> und entsprechend Konfiguriert, ehe es
>> produktiv wird.
>
>> Auf meinen Rechnern befinden sich daher genau NULL
>> Virenpackete und richten somit ebenfalls keinen Schaden an.
>
> "Man muss nur fest dran glauben!"
>
Ich weis es. Viren würden zumindest versuchen aktiv zu werden.
>> Wann sollte er sich bitte einschleichen? Das Systenm wird aufgesetzt
>> und entsprechend Konfiguriert, ehe es
>> produktiv wird.
>
>> Auf meinen Rechnern befinden sich daher genau NULL
>> Virenpackete und richten somit ebenfalls keinen Schaden an.
>
> "Man muss nur fest dran glauben!"
>
Das würde ich in meinen LOGS sehen. Das mal etwas "drive by" in
irgendeinem TEMP Verzeichnis landet
und sich versucht von dort aus weiter zu kopieren oder sich auszuführen
kommt vor.
Dies misslingt aber zuverlässig und ist im LOG ersichtlich. Das ausführen
wird verhindert, der Inhalt des TEMP
ohnehin regelmässig gelöscht. ENDE
Immernoch besser als 30 installierte Virenpackete, die du ja scheinbar
nicht mal mehr löschen kannst, da sie sich
wohl schon installiert haben. Oder warum haust du sie nicht einfach runter?
>>> Ich verlagere den grössten Teil der Arbeit auf Automaten - reicht
>>> bei meinen Rechnern. Und entlastet mich.
>>>
>
>> Und das ist eben ein Irrglaube und weit verbreiteter Mythos. Es gibt
>> nun mal keine Sicherheit auf Knopfdruck.
>
> Habe ich nirgendwo behauptet, also musst Du nichts derartiges
> widerlegen.
>
Die Aussage, dass du die meiste Arbeit "Automaten" überlässt, klingt dann
>>>
>
>> Und das ist eben ein Irrglaube und weit verbreiteter Mythos. Es gibt
>> nun mal keine Sicherheit auf Knopfdruck.
>
> Habe ich nirgendwo behauptet, also musst Du nichts derartiges
> widerlegen.
>
aber doch sehr nach
diesem Irrglauben.
>> Es gibt ebensowenig Sicherheit, dadurch, dass man einmal etwas
>> und sich denkt "Nun bin ich ja sicher".
>
> Aha!
>
> Wer sagte gerade eben "Auf meinen Rechnern befinden sich daher genau
> NULL Virenpackete und richten somit ebenfalls keinen Schaden an."?
>
Woher ich das aktuell weiß, habe ich oben begründet. Sieh diese Aussage
>
> Aha!
>
> Wer sagte gerade eben "Auf meinen Rechnern befinden sich daher genau
> NULL Virenpackete und richten somit ebenfalls keinen Schaden an."?
>
bitte im Zusammenhang und
beziehe sie nicht auf einen Satz.
>> Nein, es ist vielmehr ein immerwährender Prozess und bedarf ständiger
>> Aufmerksamkeit.
>> Es müssen ständig Logs geprüft, Prozesse wie Installationen gründlich
>> geplant und durchgeführt
>> und somit ein gewisser Aufwand betrieben werden, wenn man auf
>> Sicherheit wirklich Wert legt.
>> Alles Andere ist Augenwischerei.
>
> Eben - das kann ich mit wenig weiterem Aufwand haben - wie bei meinen
> Rechnern seit etwa 20 Jahren - oder aber mit viel weiterem Aufwand.
>
Wenn du den erforderlichen Aufwand betreibst, kannst du auf AV Software
>> Sicherheit wirklich Wert legt.
>> Alles Andere ist Augenwischerei.
>
> Eben - das kann ich mit wenig weiterem Aufwand haben - wie bei meinen
> Rechnern seit etwa 20 Jahren - oder aber mit viel weiterem Aufwand.
>
verzichten,
denn dann ist sie schlicht überflüssig.
> Also bleibe ich bei meinen Verfahren.
>
deiner Frage, an ernsthaftem
Interesse im Zuge der ständigen Weiterentwicklung und dem Überdenken des
eigenen Sicherheitskonzeptes
deinerseits aus und wollte dir so viele Informationen als Antwort geben,
wie möglich.
Dachte du wolltest dir da möglicherweise ein paar Anregungen raus ziehen.
Und nicht, dein nicht näher beschriebes
Konzept verteidigen.
Stefan Kanthak
Jun 6, 2012, 2:07:35 PM6/6/12
to
"Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
> Hallo,
>
> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
>
> Stefan, du bist sicherlich bei Windows ein kompetenter und empfehlenswerter
> Ratgeber, in diesem Fall liegst du aber wirklich daneben ...
Ich habe seit Monaten kein UNIX mehr angefasst.
Frueher[TM] taeglich (und LANGE vor DOS oder Windows) ...
> ----------------
> iilse@ubuntu:~$ ls -l bla.out
> ls: Zugriff auf bla.out nicht möglich: Datei oder Verzeichnis nicht gefunden
> In meinem oben zitierten Compileraufruf ist keinerlei "chmod" im Spiel.
und daher das bekannte vi^W$EDITOR-Verhalten, --x--x--x nicht zu setzen,
unzulaessig verallgemeinert.
Dummerweise tut das meiner Argumentation keinen Abbruch: Uwe sollte den
Unterschied zwischen Windows und UNIX kapieren!
JFTR: $SHELL -c *.sh verhaelt sich genauso wie %COMSPEC% /C CALL *.CMD
aber darum geht's auch nicht!
Unter Windows sind ALLE Dateien, auch mit dem Browser heruntergeladene
oder vom MUA gespeicherte, ohne weiteres Zutun ausfuehrbar (das
ShellExecute() bei im NTFS-ADS abgelegten "stammt aus dem Internet" ggf.
warnt ist irrelevant, denn CreateProcess() warnt selbstverstaendlich
nicht).
Unter UNIX sind sie es dagegen nicht.
Stefan
PS: Ja, "chmod +x ..." kann jeder $BENUTZER aufrufen, und es wirkt
sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
haette er die Datei dort aber auch gar nicht anlegen koennen).
Unter Windows kann man stattdessen die ACE "(D;OIIO;WP;;;WD)" auf
"%USERPROFILE%" und "%ALLUSERSPROFILE%" setzen: verweigere (D)
allen Benutzern (WD = "WORLD\Everyone") das Ausfuehren (WP) von
Dateien (OI) in diesem Verzeichnis und den Unterverzeichnissen (IO).
Ja, ein Benutzer kann diese ACE von seinen eigenen Dateien entfernen.
ONU wird es i.d.R. aber nicht koennen.
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
> Hallo,
>
> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
>
> Stefan, du bist sicherlich bei Windows ein kompetenter und empfehlenswerter
> Ratgeber, in diesem Fall liegst du aber wirklich daneben ...
Frueher[TM] taeglich (und LANGE vor DOS oder Windows) ...
> ----------------
> iilse@ubuntu:~$ ls -l bla.out
> ilse@ubuntu:~$ echo 'int main(){return 0;}' | gcc -o bla.out -x c -
> ilse@ubuntu:~$ ls -l bla.out
> -rwxrwxr-x 1 ilse ilse 7115 Jun 6 11:14 bla.out
> ilse@ubuntu:~$ umask
> 0002
> ilse@ubuntu:~$
> ----------------
[...]
> ilse@ubuntu:~$ ls -l bla.out
> -rwxrwxr-x 1 ilse ilse 7115 Jun 6 11:14 bla.out
> ilse@ubuntu:~$ umask
> 0002
> ilse@ubuntu:~$
> ----------------
> In meinem oben zitierten Compileraufruf ist keinerlei "chmod" im Spiel.
unzulaessig verallgemeinert.
Dummerweise tut das meiner Argumentation keinen Abbruch: Uwe sollte den
Unterschied zwischen Windows und UNIX kapieren!
JFTR: $SHELL -c *.sh verhaelt sich genauso wie %COMSPEC% /C CALL *.CMD
aber darum geht's auch nicht!
Unter Windows sind ALLE Dateien, auch mit dem Browser heruntergeladene
oder vom MUA gespeicherte, ohne weiteres Zutun ausfuehrbar (das
ShellExecute() bei im NTFS-ADS abgelegten "stammt aus dem Internet" ggf.
warnt ist irrelevant, denn CreateProcess() warnt selbstverstaendlich
nicht).
Unter UNIX sind sie es dagegen nicht.
Stefan
PS: Ja, "chmod +x ..." kann jeder $BENUTZER aufrufen, und es wirkt
sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
haette er die Datei dort aber auch gar nicht anlegen koennen).
Unter Windows kann man stattdessen die ACE "(D;OIIO;WP;;;WD)" auf
"%USERPROFILE%" und "%ALLUSERSPROFILE%" setzen: verweigere (D)
allen Benutzern (WD = "WORLD\Everyone") das Ausfuehren (WP) von
Dateien (OI) in diesem Verzeichnis und den Unterverzeichnissen (IO).
Ja, ein Benutzer kann diese ACE von seinen eigenen Dateien entfernen.
ONU wird es i.d.R. aber nicht koennen.
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Helmut Hullen
Jun 6, 2012, 2:36:00 PM6/6/12
to
Hallo, Daniel,
Du meintest am 06.06.12:
Du meintest am 06.06.12:
>>> Das Konzept, welches du favorisierst, ist, erst mal alles jedem auf
>>> dem Rechner zu erlauben.
>>
>> Nein.
>> Du gehst von einer falschen Annahme aus. Damit taugen die
>> Schlussfolgerungen nichts.
>>
> Was ist Softwareblacklisteing, also ein Av denn dann, vom Prinzip
> her? Alles zulassen und unerwünschtes Blacklisten,
> Thats AV-Software.
> Würdest du Whitelisting verwenden, bräuchtest du kein Blacklisting
> mehr. Dein AV wäre schlich überflüssig.
> Daher meine Schlussfolgerung.
Sie ist falsch. Weil Du von falschen Annahmen ausgehst.
>>> dem Rechner zu erlauben.
>>
>> Nein.
>> Du gehst von einer falschen Annahme aus. Damit taugen die
>> Schlussfolgerungen nichts.
>>
> Was ist Softwareblacklisteing, also ein Av denn dann, vom Prinzip
> her? Alles zulassen und unerwünschtes Blacklisten,
> Thats AV-Software.
> Würdest du Whitelisting verwenden, bräuchtest du kein Blacklisting
> mehr. Dein AV wäre schlich überflüssig.
> Daher meine Schlussfolgerung.
Viele Gruesse!
Helmut
Daniel Kohl
Jun 6, 2012, 2:44:15 PM6/6/12
to
Helmut Hullen
Jun 6, 2012, 3:18:00 PM6/6/12
to
Hallo, Daniel,
Du meintest am 06.06.12:
[...]
Du meintest am 06.06.12:
>>> Würdest du Whitelisting verwenden, bräuchtest du kein Blacklisting
>>> mehr. Dein AV wäre schlich überflüssig.
>>> Daher meine Schlussfolgerung.
>> Sie ist falsch. Weil Du von falschen Annahmen ausgehst.
> Du verwendest also kein AV?
Auch diese Annahme ist falsch.
Viele Gruesse!
Helmut
Daniel Kohl
Jun 6, 2012, 3:22:27 PM6/6/12
to
wenig raten?
Stefan Kanthak
Jun 6, 2012, 5:01:22 PM6/6/12
to
"Daniel Kohl" <cons...@hotmail.de> schrieb:
> Am 06.06.2012, 21:18 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
> Das war eine Frage! Klär mich doch einfach mal auf, oder soll ich noch ein
> wenig raten?
Weder noch!
Sondern die Fuetterung des Gruppenclowns einstellen.
Das Hullen ist seit Jahren merkbefreit sollte in jedem gutsortierten
Killfile zu finden sein.
Stefan
> Am 06.06.2012, 21:18 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
> Das war eine Frage! Klär mich doch einfach mal auf, oder soll ich noch ein
> wenig raten?
Sondern die Fuetterung des Gruppenclowns einstellen.
Das Hullen ist seit Jahren merkbefreit sollte in jedem gutsortierten
Killfile zu finden sein.
Stefan
Ansgar -59cobalt- Wiechers
Jun 6, 2012, 5:22:40 PM6/6/12
to
Daniel Kohl <cons...@hotmail.de> wrote:
> Das war eine Frage! Klär mich doch einfach mal auf, oder soll ich noch
> ein wenig raten?
Hullen ist merkbefreit und sollte in keinem wohlsortierten Killfile
> Das war eine Frage! Klär mich doch einfach mal auf, oder soll ich noch
> ein wenig raten?
fehlen.</Aufklärung>
Juergen Ilse
Jun 7, 2012, 4:14:38 AM6/7/12
to
> "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
Der Compiler-Aufruf (der dann auch gleich noch den Assembler und den Linker
aufruft) erzeugt direkt eine ausfuehrbare Datei (genaugenommen schreibt erst
der Linker das executable File). Deine Aussage. neu angelegte Dateien im
eigenen $HOME waeren erst einmal *niemals* executable, wenn man nicht aus-
druecklich die Rechte umsetzen wuerde, ist in dieser Allgemeinheit falsch.
Wenn per Texteditor neu erstellte Dateien erst einmal nicht ausfuehrbar
sind, dann nur deshalb, weil der Texteditor die Eigenschaft hat, die Datei
eben mit nicht mit executable-Rechten anzulegen. Das ist keine Eigenschaft
des Systems oder der System-Einstellungen sondern nur eine Eigenschaft
dieses einen Anwendungsprogramms "Texteditor" ...
> Dummerweise tut das meiner Argumentation keinen Abbruch: Uwe sollte den
> Unterschied zwischen Windows und UNIX kapieren!
> JFTR: $SHELL -c *.sh verhaelt sich genauso wie %COMSPEC% /C CALL *.CMD
> aber darum geht's auch nicht!
Das ist die "andere Baustelle", die Helmut in diesem Thread aufgemacht
hat, und ich hatte ihn schon darum gebeten, dass doch bitte zu unter-
lassen, weil seine Einlassung am thema vorbei gehen wuerde ...
> Unter Windows sind ALLE Dateien, auch mit dem Browser heruntergeladene
> oder vom MUA gespeicherte, ohne weiteres Zutun ausfuehrbar (das
> ShellExecute() bei im NTFS-ADS abgelegten "stammt aus dem Internet" ggf.
> warnt ist irrelevant, denn CreateProcess() warnt selbstverstaendlich
> nicht).
> Unter UNIX sind sie es dagegen nicht.
Unter unix wird die "Ausfuehrbarkeit" durch die Dateirechte festgelegt
(und es wird zwischen "read-Recht" und "execute-Recht" unterschieden).
Die Unterscheidung zwsichen "read-Recht" und "execute-Recht" gibt es
AFAIK so beim Windows *nicht* (dafuer wird aber z.B. zwischen "schreiben"
und "aendern" unterschieden). Die "Ausfuehrbarkeit" wird im Endeffekt
durch den "Systemoberbau" durch den Zusammenhang mit dem Dateinamen und
den dafuer eingestellten Methoden zum oeffnen von Dateien festgemacht
(solange kein SRP im Spiel ist). Deswegen halte ich es auch fuer fatal,
per Default die "Dateiendungen" (die ja in diesem System eine so grosse
Bedeutung gewinnen) auszublenden ... Die Microsoft-Entwickler (oder
zumindest die Leute, die die Default-Einstellungen fuer Windows erstellt
haben) scheinen das aber (leider) anders zu sehen ...
:-(
> PS: Ja, "chmod +x ..." kann jeder $BENUTZER aufrufen, und es wirkt
> sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
> haette er die Datei dort aber auch gar nicht anlegen koennen).
Du irrst:
---------------------
ilse@ubuntu:~$ sudo -s
[sudo] password for ilse:
root@ubuntu:~# touch datei_von_root
root@ubuntu:~# chmod a+rw datei_von_root
root@ubuntu:~# exit
ilse@ubuntu:~$ chmod a+x datei_von_root
chmod: Beim Setzen der Zugriffsrechte für »datei_von_root???: Die Operation ist nicht erlaubt
ilse@ubuntu:~$ ls -l datei_von_root
-rw-rw-rw- 1 root root 0 Jun 7 10:11 datei_von_root
ilse@ubuntu:~$
----------------------
Allerdings darf jeder die Zugriffsrechte auf seine eigenen Dateien
beliebig aendern, nicht jedoch auf Dateien anderer Benutzer.
>> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>
>>> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
>> Stefan, du bist sicherlich bei Windows ein kompetenter und empfehlenswerter
>> Ratgeber, in diesem Fall liegst du aber wirklich daneben ...
>
>>> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
>> Stefan, du bist sicherlich bei Windows ein kompetenter und empfehlenswerter
>> Ratgeber, in diesem Fall liegst du aber wirklich daneben ...
>> ----------------
>> iilse@ubuntu:~$ ls -l bla.out
>> ls: Zugriff auf bla.out nicht möglich: Datei oder Verzeichnis nicht gefunden
>> ilse@ubuntu:~$ echo 'int main(){return 0;}' | gcc -o bla.out -x c -
>> ilse@ubuntu:~$ ls -l bla.out
>> -rwxrwxr-x 1 ilse ilse 7115 Jun 6 11:14 bla.out
>> ilse@ubuntu:~$ umask
>> 0002
>> ilse@ubuntu:~$
>> ----------------
> [...]
>> In meinem oben zitierten Compileraufruf ist keinerlei "chmod" im Spiel.
> und daher das bekannte vi^W$EDITOR-Verhalten, --x--x--x nicht zu setzen,
> unzulaessig verallgemeinert.
???
>> iilse@ubuntu:~$ ls -l bla.out
>> ls: Zugriff auf bla.out nicht möglich: Datei oder Verzeichnis nicht gefunden
>> ilse@ubuntu:~$ echo 'int main(){return 0;}' | gcc -o bla.out -x c -
>> ilse@ubuntu:~$ ls -l bla.out
>> -rwxrwxr-x 1 ilse ilse 7115 Jun 6 11:14 bla.out
>> ilse@ubuntu:~$ umask
>> 0002
>> ilse@ubuntu:~$
>> ----------------
> [...]
>> In meinem oben zitierten Compileraufruf ist keinerlei "chmod" im Spiel.
> und daher das bekannte vi^W$EDITOR-Verhalten, --x--x--x nicht zu setzen,
> unzulaessig verallgemeinert.
Der Compiler-Aufruf (der dann auch gleich noch den Assembler und den Linker
aufruft) erzeugt direkt eine ausfuehrbare Datei (genaugenommen schreibt erst
der Linker das executable File). Deine Aussage. neu angelegte Dateien im
eigenen $HOME waeren erst einmal *niemals* executable, wenn man nicht aus-
druecklich die Rechte umsetzen wuerde, ist in dieser Allgemeinheit falsch.
Wenn per Texteditor neu erstellte Dateien erst einmal nicht ausfuehrbar
sind, dann nur deshalb, weil der Texteditor die Eigenschaft hat, die Datei
eben mit nicht mit executable-Rechten anzulegen. Das ist keine Eigenschaft
des Systems oder der System-Einstellungen sondern nur eine Eigenschaft
dieses einen Anwendungsprogramms "Texteditor" ...
> Dummerweise tut das meiner Argumentation keinen Abbruch: Uwe sollte den
> Unterschied zwischen Windows und UNIX kapieren!
> JFTR: $SHELL -c *.sh verhaelt sich genauso wie %COMSPEC% /C CALL *.CMD
> aber darum geht's auch nicht!
hat, und ich hatte ihn schon darum gebeten, dass doch bitte zu unter-
lassen, weil seine Einlassung am thema vorbei gehen wuerde ...
> Unter Windows sind ALLE Dateien, auch mit dem Browser heruntergeladene
> oder vom MUA gespeicherte, ohne weiteres Zutun ausfuehrbar (das
> ShellExecute() bei im NTFS-ADS abgelegten "stammt aus dem Internet" ggf.
> warnt ist irrelevant, denn CreateProcess() warnt selbstverstaendlich
> nicht).
> Unter UNIX sind sie es dagegen nicht.
(und es wird zwischen "read-Recht" und "execute-Recht" unterschieden).
Die Unterscheidung zwsichen "read-Recht" und "execute-Recht" gibt es
AFAIK so beim Windows *nicht* (dafuer wird aber z.B. zwischen "schreiben"
und "aendern" unterschieden). Die "Ausfuehrbarkeit" wird im Endeffekt
durch den "Systemoberbau" durch den Zusammenhang mit dem Dateinamen und
den dafuer eingestellten Methoden zum oeffnen von Dateien festgemacht
(solange kein SRP im Spiel ist). Deswegen halte ich es auch fuer fatal,
per Default die "Dateiendungen" (die ja in diesem System eine so grosse
Bedeutung gewinnen) auszublenden ... Die Microsoft-Entwickler (oder
zumindest die Leute, die die Default-Einstellungen fuer Windows erstellt
haben) scheinen das aber (leider) anders zu sehen ...
:-(
> PS: Ja, "chmod +x ..." kann jeder $BENUTZER aufrufen, und es wirkt
> sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
> haette er die Datei dort aber auch gar nicht anlegen koennen).
---------------------
ilse@ubuntu:~$ sudo -s
[sudo] password for ilse:
root@ubuntu:~# touch datei_von_root
root@ubuntu:~# chmod a+rw datei_von_root
root@ubuntu:~# exit
ilse@ubuntu:~$ chmod a+x datei_von_root
chmod: Beim Setzen der Zugriffsrechte für »datei_von_root???: Die Operation ist nicht erlaubt
ilse@ubuntu:~$ ls -l datei_von_root
-rw-rw-rw- 1 root root 0 Jun 7 10:11 datei_von_root
ilse@ubuntu:~$
----------------------
Allerdings darf jeder die Zugriffsrechte auf seine eigenen Dateien
beliebig aendern, nicht jedoch auf Dateien anderer Benutzer.
Burkhard Ott
Jun 7, 2012, 11:28:51 AM6/7/12
to
On Wed, 06 Jun 2012 09:29:18 +0000, Juergen Ilse wrote:
> Hallo,
>
> Burkhard Ott <news...@derith.de> wrote:
>> Und? Hier spart man sich das tippen, ob nun das make file den compiler
>> aufruft oder Du das eintippst ist relativ bummi. Solange Du deine umask
>> 002 hast wird das binary immer 755 angelegt.
>
> Auch wenn es sicherlich nur ein Fluechtigkeitsafehler war: Bei umask 002
> werden die Dateirechte 775 werden, fuer 755 als Dateirechte muesste die
> umask auf 022 stehen ...
Ack, 022 ist die dafault Einstellung da hast Du Recht.
cheers
> Hallo,
>
> Burkhard Ott <news...@derith.de> wrote:
>> Und? Hier spart man sich das tippen, ob nun das make file den compiler
>> aufruft oder Du das eintippst ist relativ bummi. Solange Du deine umask
>> 002 hast wird das binary immer 755 angelegt.
>
> Auch wenn es sicherlich nur ein Fluechtigkeitsafehler war: Bei umask 002
> werden die Dateirechte 775 werden, fuer 755 als Dateirechte muesste die
> umask auf 022 stehen ...
Ack, 022 ist die dafault Einstellung da hast Du Recht.
cheers
Stefan Kanthak
Jun 7, 2012, 1:15:02 PM6/7/12
to
"Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
> Hallo,
>
> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>> "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
>>> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>>
>>>> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
>> unzulaessig verallgemeinert.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ???
Mein Satz beginnt vor dem Zitat!
> Der Compiler-Aufruf (der dann auch gleich noch den Assembler und den Linker
> aufruft) erzeugt direkt eine ausfuehrbare Datei (genaugenommen schreibt erst
> der Linker das executable File). Deine Aussage. neu angelegte Dateien im
> eigenen $HOME waeren erst einmal *niemals* executable, wenn man nicht aus-
> druecklich die Rechte umsetzen wuerde, ist in dieser Allgemeinheit falsch.
Richtig. Ich hab's extra fuer Dich nochmal unterstrichen!
Es geht darum, welche von Otto Normalbenutzer mit den von ihm typischerweise
verwendeten Anwendungen (Web-Browser, Messenger, Office-Krimskrams, ...)
erstellten Dateien "ausfuehrbar" sind (oder sein muessen). ONU verwendet
typischerweise weder "cc" noch "make"!
> Wenn per Texteditor neu erstellte Dateien erst einmal nicht ausfuehrbar
> sind, dann nur deshalb, weil der Texteditor die Eigenschaft hat, die Datei
> eben mit nicht mit executable-Rechten anzulegen. Das ist keine Eigenschaft
> des Systems oder der System-Einstellungen sondern nur eine Eigenschaft
> dieses einen Anwendungsprogramms "Texteditor" ...
Modulo der Einstellung von umask...
>> Unter Windows sind ALLE Dateien, auch mit dem Browser heruntergeladene
>> oder vom MUA gespeicherte, ohne weiteres Zutun ausfuehrbar (das
>> ShellExecute() bei im NTFS-ADS abgelegten "stammt aus dem Internet" ggf.
>> warnt ist irrelevant, denn CreateProcess() warnt selbstverstaendlich
>> nicht).
>> Unter UNIX sind sie es dagegen nicht.
>
> Unter unix wird die "Ausfuehrbarkeit" durch die Dateirechte festgelegt
> (und es wird zwischen "read-Recht" und "execute-Recht" unterschieden).
Korrekt.
> Die Unterscheidung zwsichen "read-Recht" und "execute-Recht" gibt es
> AFAIK so beim Windows *nicht*
Falsch!
Windows kennt
1. die generischen Rechte (<http://msdn.microsoft.com/en-us/aa446632.aspx>)
"generic write", "generic read", "generic execute" und "generic all":
diese generischen Rechte werden auf Mengen/Kombinationen spezieller
Rechte abgebildet (wobei diese Abbildung auf verschiedenen Windows-
Versionen unterschiedlich, aber per Win32-API erfragbar ist).
2. die "einfachen" Rechte "Vollzugriff", "Aendern", "Lesen/Ausfuehren",
"Lesen" und "Schreiben": auch diese sind auf Kombinationen spezieller
Rechte abgebildet.
3. die "speziellen" (eigentlich: elementaren) Rechte:
(<http://msdn.microsoft.com/en-us/aa379607.aspx>,
<http://msdn.microsoft.com/en-us/aa364399.aspx>,
<http://msdn.microsoft.com/en-us/aa446614.aspx>,
<http://msdn.microsoft.com/en-us/ms724878.aspx>, ...)
"Lesen", "Schreiben", "Anhaengen", "Lesen erweiterter Attribute",
"Schreiben erweiterter Attribute", "Ausfuehren" (resp. "Durchlaufen"),
"Lesen Attribute", "Schreiben Attribute", "Loeschen", ...
> (dafuer wird aber z.B. zwischen "schreiben" und "aendern" unterschieden).
Ab jetzt nur noch GIGO!
> Die "Ausfuehrbarkeit" wird im Endeffekt durch den "Systemoberbau" durch
> den Zusammenhang mit dem Dateinamen und den dafuer eingestellten Methoden
> zum oeffnen von Dateien festgemacht (solange kein SRP im Spiel ist).
Eben NICHT:
0. Rechtsklick->Eigenschaften:Sicherheit [Erweitert] [Anzeigen] zeigt
Dir ganz deutlich "Ausfuehren/Ordner durchsuchen". Entferne dieses
Recht von einer ausfuehrbaren Datei (*.EXE, genauer: Win32-PE, oder
*.COM) und versuche sie aufzufuehren. Merkst Du was?
1. Was Du als "Systemoberbau" bezeichnest wird durch ShellExecute()
realisiert: anhand des Dateityps feststellen, mit welchem Programm
eine Datei zu "Oeffnen" (oder "Auszufuehren" ist), daraus die
Kommandozeile fuer den Aufruf dieses Programms mit der zu oeffnenden
Datei basteln und diese Kommandozeile an CreateProcess() verfuettern.
Diese Arbeitsteilung ist NOTWENDIG, denn CreateProcess() startet
ausschliesslich Binaerprogramme.
2. Ein zu ShellExecute() analoger Mechanismus ist bei UNIX im Unterbau
(exec*()) vorhanden: der shebang!
Im Gegensatz zu CreateProcess() fuehrt exec*() nicht nur Binaer-
Programme, sondern auch Textdateien aus.
> Deswegen halte ich es auch fuer fatal, per Default die "Dateiendungen"
> (die ja in diesem System eine so grosse Bedeutung gewinnen) auszublenden ...
Worin unterscheidet sich das von UNIX?
Siehst Du einer Datei "foobar" am Namen an, was passiert, wenn Du sie
an exec*() verfuetterst? Oder in $SHELL aufrufst?
Ist sie ein (ausfuehrbares) Binaerprogramm, eine (nicht ausfuehrbare)
Datendatei oder ein (ausfuehrbares) {sh,bash,awk,sed,perl,...}-Skript
mit "#!/bin/interpreter -options"?
[...]
>> PS: Ja, "chmod +x ..." kann jeder $BENUTZER aufrufen, und es wirkt
>> sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
>> haette er die Datei dort aber auch gar nicht anlegen koennen).
>
> Du irrst:
Nein. Klassisches UNIX vs. POSIX (siehe auch "POSIXLY_CORRECT").
Und dann gibt's noch das "sticky bit"...
Stefan
> Hallo,
>
> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>> "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
>>> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>>
>>>> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
>>> ilse@ubuntu:~$ ls -l bla.out
>>> -rwxrwxr-x 1 ilse ilse 7115 Jun 6 11:14 bla.out
>>> -rwxrwxr-x 1 ilse ilse 7115 Jun 6 11:14 bla.out
>>> In meinem oben zitierten Compileraufruf ist keinerlei "chmod" im Spiel.
>> und daher das bekannte vi^W$EDITOR-Verhalten, --x--x--x nicht zu setzen,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> und daher das bekannte vi^W$EDITOR-Verhalten, --x--x--x nicht zu setzen,
>> unzulaessig verallgemeinert.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ???
Mein Satz beginnt vor dem Zitat!
> Der Compiler-Aufruf (der dann auch gleich noch den Assembler und den Linker
> aufruft) erzeugt direkt eine ausfuehrbare Datei (genaugenommen schreibt erst
> der Linker das executable File). Deine Aussage. neu angelegte Dateien im
> eigenen $HOME waeren erst einmal *niemals* executable, wenn man nicht aus-
> druecklich die Rechte umsetzen wuerde, ist in dieser Allgemeinheit falsch.
Es geht darum, welche von Otto Normalbenutzer mit den von ihm typischerweise
verwendeten Anwendungen (Web-Browser, Messenger, Office-Krimskrams, ...)
erstellten Dateien "ausfuehrbar" sind (oder sein muessen). ONU verwendet
typischerweise weder "cc" noch "make"!
> Wenn per Texteditor neu erstellte Dateien erst einmal nicht ausfuehrbar
> sind, dann nur deshalb, weil der Texteditor die Eigenschaft hat, die Datei
> eben mit nicht mit executable-Rechten anzulegen. Das ist keine Eigenschaft
> des Systems oder der System-Einstellungen sondern nur eine Eigenschaft
> dieses einen Anwendungsprogramms "Texteditor" ...
>> Unter Windows sind ALLE Dateien, auch mit dem Browser heruntergeladene
>> oder vom MUA gespeicherte, ohne weiteres Zutun ausfuehrbar (das
>> ShellExecute() bei im NTFS-ADS abgelegten "stammt aus dem Internet" ggf.
>> warnt ist irrelevant, denn CreateProcess() warnt selbstverstaendlich
>> nicht).
>> Unter UNIX sind sie es dagegen nicht.
>
> Unter unix wird die "Ausfuehrbarkeit" durch die Dateirechte festgelegt
> (und es wird zwischen "read-Recht" und "execute-Recht" unterschieden).
> Die Unterscheidung zwsichen "read-Recht" und "execute-Recht" gibt es
> AFAIK so beim Windows *nicht*
Windows kennt
1. die generischen Rechte (<http://msdn.microsoft.com/en-us/aa446632.aspx>)
"generic write", "generic read", "generic execute" und "generic all":
diese generischen Rechte werden auf Mengen/Kombinationen spezieller
Rechte abgebildet (wobei diese Abbildung auf verschiedenen Windows-
Versionen unterschiedlich, aber per Win32-API erfragbar ist).
2. die "einfachen" Rechte "Vollzugriff", "Aendern", "Lesen/Ausfuehren",
"Lesen" und "Schreiben": auch diese sind auf Kombinationen spezieller
Rechte abgebildet.
3. die "speziellen" (eigentlich: elementaren) Rechte:
(<http://msdn.microsoft.com/en-us/aa379607.aspx>,
<http://msdn.microsoft.com/en-us/aa364399.aspx>,
<http://msdn.microsoft.com/en-us/aa446614.aspx>,
<http://msdn.microsoft.com/en-us/ms724878.aspx>, ...)
"Lesen", "Schreiben", "Anhaengen", "Lesen erweiterter Attribute",
"Schreiben erweiterter Attribute", "Ausfuehren" (resp. "Durchlaufen"),
"Lesen Attribute", "Schreiben Attribute", "Loeschen", ...
> (dafuer wird aber z.B. zwischen "schreiben" und "aendern" unterschieden).
> Die "Ausfuehrbarkeit" wird im Endeffekt durch den "Systemoberbau" durch
> den Zusammenhang mit dem Dateinamen und den dafuer eingestellten Methoden
> zum oeffnen von Dateien festgemacht (solange kein SRP im Spiel ist).
0. Rechtsklick->Eigenschaften:Sicherheit [Erweitert] [Anzeigen] zeigt
Dir ganz deutlich "Ausfuehren/Ordner durchsuchen". Entferne dieses
Recht von einer ausfuehrbaren Datei (*.EXE, genauer: Win32-PE, oder
*.COM) und versuche sie aufzufuehren. Merkst Du was?
1. Was Du als "Systemoberbau" bezeichnest wird durch ShellExecute()
realisiert: anhand des Dateityps feststellen, mit welchem Programm
eine Datei zu "Oeffnen" (oder "Auszufuehren" ist), daraus die
Kommandozeile fuer den Aufruf dieses Programms mit der zu oeffnenden
Datei basteln und diese Kommandozeile an CreateProcess() verfuettern.
Diese Arbeitsteilung ist NOTWENDIG, denn CreateProcess() startet
ausschliesslich Binaerprogramme.
2. Ein zu ShellExecute() analoger Mechanismus ist bei UNIX im Unterbau
(exec*()) vorhanden: der shebang!
Im Gegensatz zu CreateProcess() fuehrt exec*() nicht nur Binaer-
Programme, sondern auch Textdateien aus.
> Deswegen halte ich es auch fuer fatal, per Default die "Dateiendungen"
> (die ja in diesem System eine so grosse Bedeutung gewinnen) auszublenden ...
Siehst Du einer Datei "foobar" am Namen an, was passiert, wenn Du sie
an exec*() verfuetterst? Oder in $SHELL aufrufst?
Ist sie ein (ausfuehrbares) Binaerprogramm, eine (nicht ausfuehrbare)
Datendatei oder ein (ausfuehrbares) {sh,bash,awk,sed,perl,...}-Skript
mit "#!/bin/interpreter -options"?
[...]
>> PS: Ja, "chmod +x ..." kann jeder $BENUTZER aufrufen, und es wirkt
>> sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
>> haette er die Datei dort aber auch gar nicht anlegen koennen).
>
> Du irrst:
Und dann gibt's noch das "sticky bit"...
Stefan
Helmut Hullen
Jun 7, 2012, 1:55:00 PM6/7/12
to
Hallo, Stefan,
Du meintest am 07.06.12:
>>>>> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
Viele Gruesse!
Helmut
Du meintest am 07.06.12:
>>>>> Probiers mal direkt mit "cc" und einem simplen "Hello world!"
> Es geht darum, welche von Otto Normalbenutzer mit den von ihm
> typischerweise verwendeten Anwendungen (Web-Browser, Messenger,
> Office-Krimskrams, ...) erstellten Dateien "ausfuehrbar" sind (oder
> sein muessen). ONU verwendet typischerweise weder "cc" noch "make"!
Ach ja - auch Du schiebst jetzt die passenden Einschränkungen nach.
> typischerweise verwendeten Anwendungen (Web-Browser, Messenger,
> Office-Krimskrams, ...) erstellten Dateien "ausfuehrbar" sind (oder
> sein muessen). ONU verwendet typischerweise weder "cc" noch "make"!
Viele Gruesse!
Helmut
Jens Hektor
Jun 8, 2012, 12:07:53 AM6/8/12
to
On 06.06.2012 18:59, Ansgar -59cobalt- Wiechers wrote:
> Im Gegensatz zum Handwerk läuft Software-Entwicklung nämlich
> keineswegs so ab, dass der Architekt eine Zeichnung macht, und der
> Entwickler das Werkstück dann einfach gemäß der Zeichnung anfertigt.
Deine Vorstellungen vom Handwerk sind gelinde gesagt sehr optimistisch.
> Im Gegensatz zum Handwerk läuft Software-Entwicklung nämlich
> keineswegs so ab, dass der Architekt eine Zeichnung macht, und der
> Entwickler das Werkstück dann einfach gemäß der Zeichnung anfertigt.
Juergen P. Meier
Jun 8, 2012, 2:25:35 AM6/8/12
to
Jens Hektor <hek...@rz.rwth-aachen.de>:
Also ich kenne das mit dem Handwerk und einfachen Aufgaben so:
Gib die Aufgabe *einem* Handwerker, und er ist nach einem Arbeitstag fertig.
Gib die Aufgabe *zwei* Handwerkern, und sie brauchen zwei Tage fuer.
Gib die Aufgabe *drei* Handwerkern, und nach drei Tagen brauchst du
einen Anwalt.
Da sind wir in der IT noch harmlos gegen.
Gib die Aufgabe *einem* Handwerker, und er ist nach einem Arbeitstag fertig.
Gib die Aufgabe *zwei* Handwerkern, und sie brauchen zwei Tage fuer.
Gib die Aufgabe *drei* Handwerkern, und nach drei Tagen brauchst du
einen Anwalt.
Da sind wir in der IT noch harmlos gegen.
Juergen Ilse
Jun 8, 2012, 3:10:24 AM6/8/12
to
Hallo,
Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
> "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
> "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
>>> PS: Ja, "chmod +x ..." kann jeder $BENUTZER aufrufen, und es wirkt
>>> sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
>>> haette er die Datei dort aber auch gar nicht anlegen koennen).
>> Du irrst:
> Nein. Klassisches UNIX vs. POSIX (siehe auch "POSIXLY_CORRECT").
Ich irre nicht. Das folgende gibt uebrigens (abgesehen vom genauen Wortlaut
>>> sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
>>> haette er die Datei dort aber auch gar nicht anlegen koennen).
>> Du irrst:
> Nein. Klassisches UNIX vs. POSIX (siehe auch "POSIXLY_CORRECT").
der Fehlermeldung) das gleiche Ergebnis nicht nur wie hier unter linux son-
dern auch z.B. unter Solaris, HP/UX, AIX, *BSD, ...
----------------------
root@ubuntu:~# ls -l blubb
-rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
root@ubuntu:~# exit
ilse@ubuntu:~$ export POSIXLY_CORRECT=true
ilse@ubuntu:~$ chmod a+x blubb
chmod: Beim Setzen der Zugriffsrechte für »blubb???: Die Operation ist nicht erlaubt
ilse@ubuntu:~$ ls -l blubb
-rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
ilse@ubuntu:~$ ls -ld .
drwxr-xr-x 98 ilse ilse 12288 Jun 8 09:03 .
ilse@ubuntu:~$
-----------------------
Jeder Nutzer darf die Rechte seiner *eigenen* Dateien aendern, nicht jedoch
die Rechte fremder Dateien (auch dann nicht, wenn er im Verzeichnis Schreib-
rechte hat, noch nicht einmal dann, wenn er zusaetzlich auch noch auf die
Datei Schreibrechte hat). Nur root darf auch fuer fremde Dateien die Datei-
rechte umsetzen ...
> Und dann gibt's noch das "sticky bit"...
geschrieben hast, denn das sticky Bit ist wieder etwas voellig anderes)
und das SetGID-Bit. Nur was sollen die jetzt mit dieser Diskussion zu
tun haben?
Juergen P. Meier
Jun 8, 2012, 4:56:29 AM6/8/12
to
Juergen Ilse <jue...@usenet-verwaltung.de>:
Man koennte chmod() genauso limitieren wie ulink() und rename(), oder
es so machen wie Linux, das jeglichen chmod() auf Dateien die einem
nicht gehoeren verbietet. Oder man koennte chmod() von den
schreibrechten abhaengig machen... (man liest raus: ich bin zu faul
andere Plattformen auszuprobieren. DAs darf jeder selbst)
POSIX FAC ist halt nunmal recht beschraenkt in den Moeglichkeiten und
bietet leider recht viel Spielraum fuer Interpretation.
>> Und dann gibt's noch das "sticky bit"...
Das auch Systemabhaengig ist und idR. nur rename()/unlink() limitiert.
> ... und das SetUID-Bit (das du vermutlich meintest, als du sticky Bit
Nein, das Sticky-Bit ist S_ISVTX oder auch t-Bit, nicht zu verwechseln
mit den Set-ID-bits S_ISUID und. S_ISGID.
> geschrieben hast, denn das sticky Bit ist wieder etwas voellig anderes)
> und das SetGID-Bit. Nur was sollen die jetzt mit dieser Diskussion zu
> tun haben?
Das Sticky-Bit beschreankt idR. den Zugriff auf Dateien im eigenen
Verzeichnis, die dem User nicht gehoeren. Allerdings ueblicherweise
nur fuer ulink() und rename().
HTH,
> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>> Nein. Klassisches UNIX vs. POSIX (siehe auch "POSIXLY_CORRECT").
>
>> Nein. Klassisches UNIX vs. POSIX (siehe auch "POSIXLY_CORRECT").
>
> root@ubuntu:~# ls -l blubb
> -rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
> -rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
> ilse@ubuntu:~$ export POSIXLY_CORRECT=true
> ilse@ubuntu:~$ chmod a+x blubb
> chmod: Beim Setzen der Zugriffsrechte für »blubb???: Die Operation ist nicht erlaubt
> ilse@ubuntu:~$ ls -l blubb
> -rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
> ilse@ubuntu:~$ ls -ld .
> drwxr-xr-x 98 ilse ilse 12288 Jun 8 09:03 .
Das ist eine eigenwillige Impelementierung von Linux. Oder auch nicht.
> ilse@ubuntu:~$ chmod a+x blubb
> chmod: Beim Setzen der Zugriffsrechte für »blubb???: Die Operation ist nicht erlaubt
> ilse@ubuntu:~$ ls -l blubb
> -rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
> ilse@ubuntu:~$ ls -ld .
> drwxr-xr-x 98 ilse ilse 12288 Jun 8 09:03 .
Man koennte chmod() genauso limitieren wie ulink() und rename(), oder
es so machen wie Linux, das jeglichen chmod() auf Dateien die einem
nicht gehoeren verbietet. Oder man koennte chmod() von den
schreibrechten abhaengig machen... (man liest raus: ich bin zu faul
andere Plattformen auszuprobieren. DAs darf jeder selbst)
POSIX FAC ist halt nunmal recht beschraenkt in den Moeglichkeiten und
bietet leider recht viel Spielraum fuer Interpretation.
>> Und dann gibt's noch das "sticky bit"...
> ... und das SetUID-Bit (das du vermutlich meintest, als du sticky Bit
mit den Set-ID-bits S_ISUID und. S_ISGID.
> geschrieben hast, denn das sticky Bit ist wieder etwas voellig anderes)
> und das SetGID-Bit. Nur was sollen die jetzt mit dieser Diskussion zu
> tun haben?
Verzeichnis, die dem User nicht gehoeren. Allerdings ueblicherweise
nur fuer ulink() und rename().
HTH,
Juergen Ilse
Jun 8, 2012, 6:55:10 AM6/8/12
to
Juergen P. Meier <nospa...@jors.net> wrote:
> Juergen Ilse <jue...@usenet-verwaltung.de>:
>> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>>> Nein. Klassisches UNIX vs. POSIX (siehe auch "POSIXLY_CORRECT").
>>
>> root@ubuntu:~# ls -l blubb
>> -rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
>> ilse@ubuntu:~$ export POSIXLY_CORRECT=true
>> ilse@ubuntu:~$ chmod a+x blubb
>> chmod: Beim Setzen der Zugriffsrechte für »blubb???: Die Operation ist nicht erlaubt
>> ilse@ubuntu:~$ ls -l blubb
>> -rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
>> ilse@ubuntu:~$ ls -ld .
>> drwxr-xr-x 98 ilse ilse 12288 Jun 8 09:03 .
>
> Das ist eine eigenwillige Impelementierung von Linux. Oder auch nicht.
"Nicht".
> Juergen Ilse <jue...@usenet-verwaltung.de>:
>> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>>> Nein. Klassisches UNIX vs. POSIX (siehe auch "POSIXLY_CORRECT").
>>
>> root@ubuntu:~# ls -l blubb
>> -rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
>> ilse@ubuntu:~$ export POSIXLY_CORRECT=true
>> ilse@ubuntu:~$ chmod a+x blubb
>> chmod: Beim Setzen der Zugriffsrechte für »blubb???: Die Operation ist nicht erlaubt
>> ilse@ubuntu:~$ ls -l blubb
>> -rw-rw-rw- 1 root root 0 Jun 8 09:02 blubb
>> ilse@ubuntu:~$ ls -ld .
>> drwxr-xr-x 98 ilse ilse 12288 Jun 8 09:03 .
>
> Das ist eine eigenwillige Impelementierung von Linux. Oder auch nicht.
Unter Solaris sieht es im Prinzip genauso aus:
------------------
~ # touch bla
~ # chmod a=rw bla
~ # exit
~ $ ls -l bla
-rw-rw-rw- 1 root 0 Jun 8 12:47 bla
~ $ ls -ld .
drwxr-xr-x 94 ilse 61952 Jun 8 12:47 .
~ $ chmod a+x bla
chmod: WARNING: can't change bla
~ $
-------------------
Das war jetzt unter Solaris 10 auf Sparc Hardware.
> Man koennte chmod() genauso limitieren wie ulink() und rename(), oder
> es so machen wie Linux, das jeglichen chmod() auf Dateien die einem
> nicht gehoeren verbietet.
unixoiden Systeme sondern das Verhalten wie es Stefan beschrieben hat.
OK, dann nehme ich das "Nicht" zurueck ...
> POSIX FAC ist halt nunmal recht beschraenkt in den Moeglichkeiten und
> bietet leider recht viel Spielraum fuer Interpretation.
zusaetzlich ...
>>> Und dann gibt's noch das "sticky bit"...
> Das auch Systemabhaengig ist und idR. nur rename()/unlink() limitiert.
>> ... und das SetUID-Bit (das du vermutlich meintest, als du sticky Bit
> Nein, das Sticky-Bit ist S_ISVTX oder auch t-Bit, nicht zu verwechseln
> mit den Set-ID-bits S_ISUID und. S_ISGID.
Sticky in den Postings im Usenet munter durcheinandergeworfen werden ...
>> geschrieben hast, denn das sticky Bit ist wieder etwas voellig anderes)
>> und das SetGID-Bit. Nur was sollen die jetzt mit dieser Diskussion zu
>> tun haben?
> Das Sticky-Bit beschreankt idR. den Zugriff auf Dateien im eigenen
> Verzeichnis, die dem User nicht gehoeren.
Systemen ohnehin nur root die Rechte auf fremde Dateien aendern, alle
anderen duerfen nur an den Rechten der eigenen Dateien fummeln ...).
> Allerdings ueblicherweise nur fuer ulink() und rename().
Ansgar -59cobalt- Wiechers
Jun 8, 2012, 9:04:00 AM6/8/12
to
selbst. Im Handwerk ist das, was ich oben schrieb, aber immerhin noch
ansatzweise realistisch. Für Software-Entwicklung hingegen ist es völlig
illusorisch.
Daniel Kohl
Jun 8, 2012, 11:07:01 AM6/8/12
to
Hier mal noch ein aktuelles Beispiel, wie toll AVs schützen:
http://www.heise.de/newsticker/meldung/Virenpost-durch-Postviren-1614043.html
"Eine Hand voll"
Und ich wette, das sind nicht die am weitesten verbreiteten, denn dort
wurde sicher
gegengetestet.
http://www.heise.de/newsticker/meldung/Virenpost-durch-Postviren-1614043.html
"Eine Hand voll"
Und ich wette, das sind nicht die am weitesten verbreiteten, denn dort
wurde sicher
gegengetestet.
Helmut Hullen
Jun 8, 2012, 12:28:00 PM6/8/12
to
Hallo, Daniel,
Du meintest am 08.06.12:
> Hier mal noch ein aktuelles Beispiel, wie toll AVs schützen:
> http://www.heise.de/newsticker/meldung/Virenpost-durch-Postviren-1614
> 043.html
> "Eine Hand voll"
Das ist das prinzipbedingte Problem von Virenscannern: ganz neue Viren
erkennen sie nicht unbedingt.
Schön, dass auch Du das weisst.
Meine E-Mail-Provider benutzen weitere Programme, die bisher jedes Paket
dieser Art als verdächtig markiert haben, mein lokaler Filter reagiert
brav darauf und packt solche Pakete in ein spezielles Verzeichnis.
Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz. Die Programme
meiner Provider auch nicht. Brain 1.x auch nicht.
Ist alles altbekannt. Jedenfalls für die allermeisten Leser in dieser
Newsgroup.
Viele Gruesse!
Helmut
Du meintest am 08.06.12:
> Hier mal noch ein aktuelles Beispiel, wie toll AVs schützen:
> http://www.heise.de/newsticker/meldung/Virenpost-durch-Postviren-1614
> 043.html
> "Eine Hand voll"
erkennen sie nicht unbedingt.
Schön, dass auch Du das weisst.
Meine E-Mail-Provider benutzen weitere Programme, die bisher jedes Paket
dieser Art als verdächtig markiert haben, mein lokaler Filter reagiert
brav darauf und packt solche Pakete in ein spezielles Verzeichnis.
Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz. Die Programme
meiner Provider auch nicht. Brain 1.x auch nicht.
Ist alles altbekannt. Jedenfalls für die allermeisten Leser in dieser
Newsgroup.
Viele Gruesse!
Helmut
Stefan Kanthak
Jun 8, 2012, 9:20:38 AM6/8/12
to
"Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
> Hallo,
>
> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>> "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
>>>> PS: Ja, "chmod +x ..." kann jeder $BENUTZER aufrufen, und es wirkt
>>>> sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
>>>> haette er die Datei dort aber auch gar nicht anlegen koennen).
>>> Du irrst:
>> Nein. Klassisches UNIX vs. POSIX (siehe auch "POSIXLY_CORRECT").
>
> Ich irre nicht.
Stimmt.
> Jeder Nutzer darf die Rechte seiner *eigenen* Dateien aendern, nicht jedoch
> die Rechte fremder Dateien (auch dann nicht, wenn er im Verzeichnis Schreib-
> rechte hat, noch nicht einmal dann, wenn er zusaetzlich auch noch auf die
> Datei Schreibrechte hat).
Korrekt.
Ich habe fuer chmod() faelschlich^Wbloederweise einen Zugriff aufs
Directory angenommen. Dort steht aber nur der Dateiname; die Attribute
der Datei stehen in deren inode.
> Nur root darf auch fuer fremde Dateien die Dateirechte umsetzen ...
> und das SetGID-Bit.
Zum (Anlegen und) Loeschen von Dateien ist Schreibzugriff im Verzeichnis
noetig.
Ohne "sticky bit" kann ein Benutzer mit Schreibzugriff im Verzeichnis
die Dateien anderer Benutzer loeschen, auch wenn er auf die Dateien
selbst keinen Zugriff hat.
Mit "sticky bit" muss ein Benutzer Eigentuemer der Datei oder des
Verzeichnis oder "root" sein.
> Nur was sollen die jetzt mit dieser Diskussion zu tun haben?
Deren Komplexitaet erhoehen. Den Hinweis auf chmod() hatte ich als PS
geschrieben-
> Hallo,
>
> Stefan Kanthak <dont.delete-this.don...@expires-2012-02-29.arcornews.de> wrote:
>> "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
>>>> PS: Ja, "chmod +x ..." kann jeder $BENUTZER aufrufen, und es wirkt
>>>> sogar, wenn $BENUTZER Schreibrechte im Verzeichnis hat (sonst
>>>> haette er die Datei dort aber auch gar nicht anlegen koennen).
>>> Du irrst:
>> Nein. Klassisches UNIX vs. POSIX (siehe auch "POSIXLY_CORRECT").
>
> Ich irre nicht.
> Jeder Nutzer darf die Rechte seiner *eigenen* Dateien aendern, nicht jedoch
> die Rechte fremder Dateien (auch dann nicht, wenn er im Verzeichnis Schreib-
> rechte hat, noch nicht einmal dann, wenn er zusaetzlich auch noch auf die
> Datei Schreibrechte hat).
Ich habe fuer chmod() faelschlich^Wbloederweise einen Zugriff aufs
Directory angenommen. Dort steht aber nur der Dateiname; die Attribute
der Datei stehen in deren inode.
> Nur root darf auch fuer fremde Dateien die Dateirechte umsetzen ...
>
>> Und dann gibt's noch das "sticky bit"...
>
> ... und das SetUID-Bit (das du vermutlich meintest, als du sticky Bit
> geschrieben hast, denn das sticky Bit ist wieder etwas voellig anderes)
Ich meine, was ich schreibe!
>> Und dann gibt's noch das "sticky bit"...
>
> ... und das SetUID-Bit (das du vermutlich meintest, als du sticky Bit
> geschrieben hast, denn das sticky Bit ist wieder etwas voellig anderes)
> und das SetGID-Bit.
Zum (Anlegen und) Loeschen von Dateien ist Schreibzugriff im Verzeichnis
noetig.
Ohne "sticky bit" kann ein Benutzer mit Schreibzugriff im Verzeichnis
die Dateien anderer Benutzer loeschen, auch wenn er auf die Dateien
selbst keinen Zugriff hat.
Mit "sticky bit" muss ein Benutzer Eigentuemer der Datei oder des
Verzeichnis oder "root" sein.
> Nur was sollen die jetzt mit dieser Diskussion zu tun haben?
geschrieben-
Lars Gebauer
Jun 8, 2012, 2:00:21 PM6/8/12
to
* Helmut Hullen:
> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
Es würde weiterhelfen, wenn man den Schutz den sie bieten (wollen),
korrekt definieren könnte. Solange das nicht geht ist ein auf
Virenscannern basierendes Konzept pure Esoterik.
Wenn jemand sagt "Virenscanner sind Teil eines /umfassenderen)
Konzeptes", dann könnte man in dieses Konzept auch das Schlachten von
schwarzen Hühnern bei Mitternacht aufnehmen. Schadet ja nicht aber hilft
vielleicht. Manchmal.
> Das ist das prinzipbedingte Problem von Virenscannern: ganz neue Viren
> erkennen sie nicht unbedingt.
Mit "nicht unbedingt" meinst Du "gar nicht"?
> erkennen sie nicht unbedingt.
> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
korrekt definieren könnte. Solange das nicht geht ist ein auf
Virenscannern basierendes Konzept pure Esoterik.
Wenn jemand sagt "Virenscanner sind Teil eines /umfassenderen)
Konzeptes", dann könnte man in dieses Konzept auch das Schlachten von
schwarzen Hühnern bei Mitternacht aufnehmen. Schadet ja nicht aber hilft
vielleicht. Manchmal.
Helmut Hullen
Jun 8, 2012, 3:25:00 PM6/8/12
to
Hallo, Lars,
Du meintest am 08.06.12:
>> Das ist das prinzipbedingte Problem von Virenscannern: ganz neue
>> Viren erkennen sie nicht unbedingt.
> Mit "nicht unbedingt" meinst Du "gar nicht"?
Nein.
>> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
> Es würde weiterhelfen, wenn man den Schutz den sie bieten (wollen),
> korrekt definieren könnte. Solange das nicht geht ist ein auf
> Virenscannern basierendes Konzept pure Esoterik.
So wie jeder andere Schutzmechanismus auch. Auch bei anderen
Schutzmechanismen kann der Schutz nicht "korrekt" definiert werden.
Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
Viele Gruesse!
Helmut
Du meintest am 08.06.12:
>> Das ist das prinzipbedingte Problem von Virenscannern: ganz neue
>> Viren erkennen sie nicht unbedingt.
> Mit "nicht unbedingt" meinst Du "gar nicht"?
>> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
> Es würde weiterhelfen, wenn man den Schutz den sie bieten (wollen),
> korrekt definieren könnte. Solange das nicht geht ist ein auf
> Virenscannern basierendes Konzept pure Esoterik.
Schutzmechanismen kann der Schutz nicht "korrekt" definiert werden.
Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
Viele Gruesse!
Helmut
Juergen P. Meier
Jun 9, 2012, 1:07:41 AM6/9/12
to
Lars Gebauer <lgeb...@arcor.de>:
Wegen fahrlaessigem Handeln verklagt zu werden.
Und selbst das nicht zu 100%.
> Wenn jemand sagt "Virenscanner sind Teil eines /umfassenderen)
> Konzeptes", dann könnte man in dieses Konzept auch das Schlachten von
> schwarzen Hühnern bei Mitternacht aufnehmen. Schadet ja nicht aber hilft
> vielleicht. Manchmal.
Katzen!
> * Helmut Hullen:
>> Das ist das prinzipbedingte Problem von Virenscannern: ganz neue Viren
>> erkennen sie nicht unbedingt.
>
> Mit "nicht unbedingt" meinst Du "gar nicht"?
>
>> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
>
> Es würde weiterhelfen, wenn man den Schutz den sie bieten (wollen),
> korrekt definieren könnte. Solange das nicht geht ist ein auf
> Virenscannern basierendes Konzept pure Esoterik.
AV-Software bietet Schutz prinzipiell nur vor einer sache:
>> Das ist das prinzipbedingte Problem von Virenscannern: ganz neue Viren
>> erkennen sie nicht unbedingt.
>
> Mit "nicht unbedingt" meinst Du "gar nicht"?
>
>> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
>
> Es würde weiterhelfen, wenn man den Schutz den sie bieten (wollen),
> korrekt definieren könnte. Solange das nicht geht ist ein auf
> Virenscannern basierendes Konzept pure Esoterik.
Wegen fahrlaessigem Handeln verklagt zu werden.
Und selbst das nicht zu 100%.
> Wenn jemand sagt "Virenscanner sind Teil eines /umfassenderen)
> Konzeptes", dann könnte man in dieses Konzept auch das Schlachten von
> schwarzen Hühnern bei Mitternacht aufnehmen. Schadet ja nicht aber hilft
> vielleicht. Manchmal.
Lars Gebauer
Jun 9, 2012, 5:55:28 AM6/9/12
to
* Helmut Hullen:
>>> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
>
>> Es würde weiterhelfen, wenn man den Schutz den sie bieten (wollen),
>> korrekt definieren könnte. Solange das nicht geht ist ein auf
>> Virenscannern basierendes Konzept pure Esoterik.
>
> So wie jeder andere Schutzmechanismus auch. Auch bei anderen
> Schutzmechanismen kann der Schutz nicht "korrekt" definiert werden.
Nonsens. Bei jeder tatsächlichen Sicherheitsmaßnahme gibt es eine
Spezifikation, gegen welche Form von Angriffen sie wie weit standhält.
> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
Nur so am Rande: Warum versuchst Du vom Thema abzuweichen?
>>> Das ist das prinzipbedingte Problem von Virenscannern: ganz neue
>>> Viren erkennen sie nicht unbedingt.
>
>> Mit "nicht unbedingt" meinst Du "gar nicht"?
>
> Nein.
Was dann?
>>> Viren erkennen sie nicht unbedingt.
>
>> Mit "nicht unbedingt" meinst Du "gar nicht"?
>
> Nein.
>>> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
>
>> Es würde weiterhelfen, wenn man den Schutz den sie bieten (wollen),
>> korrekt definieren könnte. Solange das nicht geht ist ein auf
>> Virenscannern basierendes Konzept pure Esoterik.
>
> So wie jeder andere Schutzmechanismus auch. Auch bei anderen
> Schutzmechanismen kann der Schutz nicht "korrekt" definiert werden.
Spezifikation, gegen welche Form von Angriffen sie wie weit standhält.
> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
Helmut Hullen
Jun 9, 2012, 6:47:00 AM6/9/12
to
Hallo, Lars,
Du meintest am 09.06.12:
>>>> Das ist das prinzipbedingte Problem von Virenscannern: ganz neue
>>>> Viren erkennen sie nicht unbedingt.
>>> Mit "nicht unbedingt" meinst Du "gar nicht"?
>> Nein.
> Was dann?
Ich meine damit "nicht unbedingt".
>>>> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
>>> Es würde weiterhelfen, wenn man den Schutz den sie bieten (wollen),
>>> korrekt definieren könnte. Solange das nicht geht ist ein auf
>>> Virenscannern basierendes Konzept pure Esoterik.
>> So wie jeder andere Schutzmechanismus auch. Auch bei anderen
>> Schutzmechanismen kann der Schutz nicht "korrekt" definiert werden.
> Nonsens. Bei jeder tatsächlichen Sicherheitsmaßnahme gibt es eine
> Spezifikation, gegen welche Form von Angriffen sie wie weit
> standhält.
Wo und wie wäre dabei das gern empfohlene "Brain 1.0" einzuordnen, wie
wäre es zu spezifizieren?
>> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
> Nur so am Rande: Warum versuchst Du vom Thema abzuweichen?
Wenn Du 1 Verfahren derart verteufelst, dann wirst Du ja sicherlich
(mindestens) ein anderes Verfahren benutzen. Welches Verfahren benutzt
Du?
Viele Gruesse!
Helmut
Du meintest am 09.06.12:
>>>> Das ist das prinzipbedingte Problem von Virenscannern: ganz neue
>>>> Viren erkennen sie nicht unbedingt.
>>> Mit "nicht unbedingt" meinst Du "gar nicht"?
>> Nein.
> Was dann?
>>>> Ach ja: Virenscanner bieten keinen 100-prozentigen Schutz.
>>> Es würde weiterhelfen, wenn man den Schutz den sie bieten (wollen),
>>> korrekt definieren könnte. Solange das nicht geht ist ein auf
>>> Virenscannern basierendes Konzept pure Esoterik.
>> So wie jeder andere Schutzmechanismus auch. Auch bei anderen
>> Schutzmechanismen kann der Schutz nicht "korrekt" definiert werden.
> Nonsens. Bei jeder tatsächlichen Sicherheitsmaßnahme gibt es eine
> Spezifikation, gegen welche Form von Angriffen sie wie weit
> standhält.
wäre es zu spezifizieren?
>> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
> Nur so am Rande: Warum versuchst Du vom Thema abzuweichen?
(mindestens) ein anderes Verfahren benutzen. Welches Verfahren benutzt
Du?
Viele Gruesse!
Helmut
Hans-Peter Matthess
Jun 9, 2012, 10:26:24 AM6/9/12
to
Juergen P. Meier:
> AV-Software bietet Schutz prinzipiell nur vor einer sache:
> Wegen fahrlaessigem Handeln verklagt zu werden.
Wo bleiben eigentlich die Leute, die die Hersteller von AV-Ware wegen
fahrlässigem Handeln verklagen? Oder: wo bleiben die Leute, die die Nutzer
von AV-Ware wegen fahrlässigem Handeln verklagen? IMHO ist es höchste Zeit
dafür.
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
> AV-Software bietet Schutz prinzipiell nur vor einer sache:
> Wegen fahrlaessigem Handeln verklagt zu werden.
fahrlässigem Handeln verklagen? Oder: wo bleiben die Leute, die die Nutzer
von AV-Ware wegen fahrlässigem Handeln verklagen? IMHO ist es höchste Zeit
dafür.
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Uwe Premer
Jun 9, 2012, 10:28:48 AM6/9/12
to
Hans-Peter Matthess schrieb am 09.06.2012 16:26 Uhr:
> Juergen P. Meier:
>
>> AV-Software bietet Schutz prinzipiell nur vor einer sache:
>> Wegen fahrlaessigem Handeln verklagt zu werden.
>
> Wo bleiben eigentlich die Leute, die die Hersteller von AV-Ware wegen
> fahrlässigem Handeln verklagen? Oder: wo bleiben die Leute, die die Nutzer
> von AV-Ware wegen fahrlässigem Handeln verklagen? IMHO ist es höchste Zeit
> dafür.
Tja, Ihr 2. Ihr seid dann gefragte Leute.
> Juergen P. Meier:
>
>> AV-Software bietet Schutz prinzipiell nur vor einer sache:
>> Wegen fahrlaessigem Handeln verklagt zu werden.
>
> Wo bleiben eigentlich die Leute, die die Hersteller von AV-Ware wegen
> fahrlässigem Handeln verklagen? Oder: wo bleiben die Leute, die die Nutzer
> von AV-Ware wegen fahrlässigem Handeln verklagen? IMHO ist es höchste Zeit
> dafür.
Also nicht aufrufen zum Verklagen, sondern selber machen!
Und, was ist jetzt?
Uwe
Hans-Peter Matthess
Jun 9, 2012, 10:46:42 AM6/9/12
to
Uwe Premer:
> Also nicht aufrufen zum Verklagen, sondern selber machen!
OK, du bekommst demnächst Post von meinem Anwalt. <eg>
> Also nicht aufrufen zum Verklagen, sondern selber machen!
Daniel Kohl
Jun 9, 2012, 11:07:08 AM6/9/12
to
Am 08.06.2012, 21:25 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
>
> Viele Gruesse!
> Helmut
>
Diesen Diskussionsstrang hatten wir doch schon, bei dem du am Ende nicht
> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
>
> Viele Gruesse!
> Helmut
>
weiter wusstest!
Aber geren nochmal: Schadsoftware erkennt man am Verhalten, nicht durch
AVs.
Wann hat jemals ein AV einen Schädling "erkannt" und nicht ein Mensch
VOR dem Rechner. Noch NIE!
Uwe Premer
Jun 9, 2012, 11:42:04 AM6/9/12
to
Hans-Peter Matthess schrieb am 09.06.2012 16:46 Uhr:
> Uwe Premer:
>
>> Also nicht aufrufen zum Verklagen, sondern selber machen!
>
> OK, du bekommst demnächst Post von meinem Anwalt. <eg>
Und da steht dann doch wieder drin, dass ich die Klage machen soll?
> Uwe Premer:
>
>> Also nicht aufrufen zum Verklagen, sondern selber machen!
>
> OK, du bekommst demnächst Post von meinem Anwalt. <eg>
Nee, lass mal stecken.
Uwe
Helmut Hullen
Jun 9, 2012, 11:27:00 AM6/9/12
to
Hallo, Daniel,
Du meintest am 09.06.12:
>> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
> Aber gern nochmal: Schadsoftware erkennt man am Verhalten, nicht
> durch AVs.
Aha - "verhaltensbasiert" ... bei Virenscannern ist das unzuverlässig.
Bei Menschen ebenfalls.
Siehe "flame".
> Wann hat jemals ein AV einen Schädling "erkannt" und nicht ein Mensch
> VOR dem Rechner. Noch NIE!
Ich habe auf mehreren (fremden) Rechnern mit Hilfe von Virenscannern
Schad-Software entdeckt.
Einige meiner Kollegen auch.
Soviel zum Umfang Deines "NIE".
Viele Gruesse!
Helmut
Du meintest am 09.06.12:
>> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
> durch AVs.
Aha - "verhaltensbasiert" ... bei Virenscannern ist das unzuverlässig.
Bei Menschen ebenfalls.
Siehe "flame".
> Wann hat jemals ein AV einen Schädling "erkannt" und nicht ein Mensch
> VOR dem Rechner. Noch NIE!
Schad-Software entdeckt.
Einige meiner Kollegen auch.
Soviel zum Umfang Deines "NIE".
Viele Gruesse!
Helmut
Daniel Kohl
Jun 9, 2012, 11:53:30 AM6/9/12
to
Am 09.06.2012, 17:27 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
> Hallo, Daniel,
>
> Du meintest am 09.06.12:
>
>>> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
>
>> Aber gern nochmal: Schadsoftware erkennt man am Verhalten, nicht
>> durch AVs.
>
> Aha - "verhaltensbasiert" ... bei Virenscannern ist das unzuverlässig.
> Bei Menschen ebenfalls.
>
> Siehe "flame".
>
Es waren Menschen, die Flame entdeckt haben, keine Software.
> Hallo, Daniel,
>
> Du meintest am 09.06.12:
>
>>> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
>
>> Aber gern nochmal: Schadsoftware erkennt man am Verhalten, nicht
>> durch AVs.
>
> Aha - "verhaltensbasiert" ... bei Virenscannern ist das unzuverlässig.
> Bei Menschen ebenfalls.
>
> Siehe "flame".
>
>> Wann hat jemals ein AV einen Schädling "erkannt" und nicht ein Mensch
>> VOR dem Rechner. Noch NIE!
>
> Ich habe auf mehreren (fremden) Rechnern mit Hilfe von Virenscannern
> Schad-Software entdeckt.
> Einige meiner Kollegen auch.
>
> Soviel zum Umfang Deines "NIE".
>
> Viele Gruesse!
> Helmut
>
Menschen
entdecken und finden. Was dein AV kann, ist Viren zu melden, die ein
Mensch zuvor
gefunden und in eine Datenbank eingepflegt hat.
Warum machst du das nicht gleich selbst? Ist ganz einfach! Benötigt kaum
Fachwissen und sollte daher
auch für dich umsetzbar sein!
Helmut Hullen
Jun 9, 2012, 2:00:00 PM6/9/12
to
Hallo, Daniel,
Du meintest am 09.06.12:
Du meintest am 09.06.12:
>>> Aber gern nochmal: Schadsoftware erkennt man am Verhalten, nicht
>>> durch AVs.
>> Aha - "verhaltensbasiert" ... bei Virenscannern ist das
>> unzuverlässig. Bei Menschen ebenfalls.
>>
>> Siehe "flame".
>>
> Es waren Menschen, die Flame entdeckt haben, keine Software.
Nein. Die Software hatte "flame" schon vor langer Zeit entdeckt.
>>> durch AVs.
>> Aha - "verhaltensbasiert" ... bei Virenscannern ist das
>> unzuverlässig. Bei Menschen ebenfalls.
>>
>> Siehe "flame".
>>
> Es waren Menschen, die Flame entdeckt haben, keine Software.
Menschen haben die Hinweise übersehen.
>>> Wann hat jemals ein AV einen Schädling "erkannt" und nicht ein
>>> Mensch VOR dem Rechner. Noch NIE!
> Und auch hier, damit dein AV den Virus "melden" konnte mussten ihn
> erst Menschen entdecken und finden. Was dein AV kann, ist Viren zu
> melden, die ein Mensch zuvor gefunden und in eine Datenbank
> eingepflegt hat.
entdecken, auch beim Rechner eines unbedarften Benutzers.
> Warum machst du das nicht gleich selbst? Ist ganz einfach! Benötigt
> kaum Fachwissen und sollte daher auch für dich umsetzbar sein!
Meinungen ein und verlasse mich nicht einzig auf mich.
Viele Gruesse!
Helmut
Hans-Peter Matthess
Jun 9, 2012, 2:44:27 PM6/9/12
to
Daniel Kohl:
> Am 09.06.2012, 17:27 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
>>>> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
Frag Herrn Hullen mal, ob und wie er abends, wenn er nach Hause kommt,
prüft, ob sich Einbrecher in der Wohnung eingenistet haben. Da wird er
sicher eine sehr umfangreiche Prozedur schildern.
> Warum machst du das nicht gleich selbst? Ist ganz einfach! Benötigt kaum
> Fachwissen und sollte daher auch für dich umsetzbar sein!
Es ist in der Tat einfach: mit einem brauchbaren Sicherheitskonzept entfällt
das Prüfen, man weiß, dass man keine Malware installiert hat bzw. keine
installieren wird.
Es gibt aber Leute mit einem krankhaften Prüffimmel, die ständig prüfen und
kontrollieren müssen. Obwohl z.B. Virenmails sofort als solche kenntlich
sind, wollen sie sie trotzdem prüfen. Sie messen sich regelmäßig auch jeden
Tag die Körpertemperatur, um die Gesundheit zu prüfen, gehen regelmäßig zum
Astrologen, um ihr Schicksal zu prüfen...
Man bezeichnet sie als Hypochonder und Esoteriker.
> Am 09.06.2012, 17:27 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
>>>> Nur am Rande: wie prüfst Du, ob Dein Rechner Schadsoftware enthält?
prüft, ob sich Einbrecher in der Wohnung eingenistet haben. Da wird er
sicher eine sehr umfangreiche Prozedur schildern.
> Warum machst du das nicht gleich selbst? Ist ganz einfach! Benötigt kaum
> Fachwissen und sollte daher auch für dich umsetzbar sein!
das Prüfen, man weiß, dass man keine Malware installiert hat bzw. keine
installieren wird.
Es gibt aber Leute mit einem krankhaften Prüffimmel, die ständig prüfen und
kontrollieren müssen. Obwohl z.B. Virenmails sofort als solche kenntlich
sind, wollen sie sie trotzdem prüfen. Sie messen sich regelmäßig auch jeden
Tag die Körpertemperatur, um die Gesundheit zu prüfen, gehen regelmäßig zum
Astrologen, um ihr Schicksal zu prüfen...
Man bezeichnet sie als Hypochonder und Esoteriker.
Daniel Kohl
Jun 9, 2012, 2:45:22 PM6/9/12
to
Am 09.06.2012, 20:00 Uhr, schrieb Helmut Hullen <Hel...@hullen.de>:
> Hallo, Daniel,
>
> Du meintest am 09.06.12:
>
>>>> Aber gern nochmal: Schadsoftware erkennt man am Verhalten, nicht
>>>> durch AVs.
>
>>> Aha - "verhaltensbasiert" ... bei Virenscannern ist das
>>> unzuverlässig. Bei Menschen ebenfalls.
>>>
>>> Siehe "flame".
>>>
>
>> Es waren Menschen, die Flame entdeckt haben, keine Software.
>
> Nein. Die Software hatte "flame" schon vor langer Zeit entdeckt.
> Menschen haben die Hinweise übersehen.
>
Und wer hat die Samples ein gesendet? Software? Unfug!
> Hallo, Daniel,
>
> Du meintest am 09.06.12:
>
>>>> Aber gern nochmal: Schadsoftware erkennt man am Verhalten, nicht
>>>> durch AVs.
>
>>> Aha - "verhaltensbasiert" ... bei Virenscannern ist das
>>> unzuverlässig. Bei Menschen ebenfalls.
>>>
>>> Siehe "flame".
>>>
>
>> Es waren Menschen, die Flame entdeckt haben, keine Software.
>
> Nein. Die Software hatte "flame" schon vor langer Zeit entdeckt.
> Menschen haben die Hinweise übersehen.
>
Die Software kann nur entdecken, was wir Menschen ihr beibringen. Liegt in
der Natur der Sache.
>
>> Und auch hier, damit dein AV den Virus "melden" konnte mussten ihn
>> erst Menschen entdecken und finden. Was dein AV kann, ist Viren zu
>> melden, die ein Mensch zuvor gefunden und in eine Datenbank
>> eingepflegt hat.
>
> Und sobald der Virus in der Datenbank ist, können Virenscanner ihn
> entdecken, auch beim Rechner eines unbedarften Benutzers.
>
Viren, die
täglich zu Anwendung kommen und nicht die Viren anno 2010, die oft eh das
neueste
Sicherheitsupdate unmöglich macht.
Der Knackpunkt ist doch, dass der Virus erstmal in Umlauf sein muß, damit
er eingepflegt werden kann.
Er muss zunächst mal ein System befallen haben, um, mit etwas Latenz,
andre Systeme davor zu bewahren.
Somit ist es nur eine Frage der Zeit, bis du derjenige bist, den es
trifft, und nicht jemand andres.
>> Warum machst du das nicht gleich selbst? Ist ganz einfach! Benötigt
>> kaum Fachwissen und sollte daher auch für dich umsetzbar sein!
>
> Weil ich meinen Fähigkeiten misstraue. Ich hole lieber noch weitere
> Meinungen ein und verlasse mich nicht einzig auf mich.
>
Und mit "andere Meinungen" meinst du jetzt die Werbeslogans
der Verkäufer, die ihr Schlangenöl los werden wollen und nicht die Meinung
von Fachleuten wie Stefan?
Komischer Ansatz, echt!
Daniel Kohl
Jun 9, 2012, 3:06:06 PM6/9/12
to
> Es gibt aber Leute mit einem krankhaften Prüffimmel, die ständig prüfen
> und
> kontrollieren müssen. Obwohl z.B. Virenmails sofort als solche kenntlich
> sind, wollen sie sie trotzdem prüfen. Sie messen sich regelmäßig auch
> jeden
> Tag die Körpertemperatur, um die Gesundheit zu prüfen, gehen regelmäßig
> zum
> Astrologen, um ihr Schicksal zu prüfen...
> Man bezeichnet sie als Hypochonder und Esoteriker.
>
"macht,
sondern ein ständiger Prozess. Das regelmäßige Validieren gegen einen
Sollzustand
ist dabei mEn Pflicht.
Deswegen bin ich doch weder Hypochonder noch Esoteriker!
Ralf Brinkmann
Jun 9, 2012, 3:08:25 PM6/9/12
to
Hallo Daniel!
*Daniel Kohl*:
> Und auch hier, damit dein AV den Virus "melden" konnte mussten ihn
> erst Menschen entdecken und finden.
Ich hab's immer gewusst: Die erste KlickTel-CD wurde von 1000 Chinesen
aus dem amtlichen Telefonbuch abgeschrieben und auch in meinem PC steckt
ein winzig kleiner, gelber Mann, der alles ganz schnell mitschreibt, was
ich außen so eintippe, den Zettel dann an andere kleine Männer
weiterreicht und am Ende sitzt dann wieder einer, der Dir von innen
einen Zettel gegen die Scheibe des sogenannten Monitors hält, damit Du
lesen kannst, was ich geschrieben habe.
Gruß, Ralf
--
Windows XP Home SP3
Opera 12.00 - 1450
The Bat! Pro 5.1.6.2
*Daniel Kohl*:
> Und auch hier, damit dein AV den Virus "melden" konnte mussten ihn
> erst Menschen entdecken und finden.
aus dem amtlichen Telefonbuch abgeschrieben und auch in meinem PC steckt
ein winzig kleiner, gelber Mann, der alles ganz schnell mitschreibt, was
ich außen so eintippe, den Zettel dann an andere kleine Männer
weiterreicht und am Ende sitzt dann wieder einer, der Dir von innen
einen Zettel gegen die Scheibe des sogenannten Monitors hält, damit Du
lesen kannst, was ich geschrieben habe.
Gruß, Ralf
--
Windows XP Home SP3
Opera 12.00 - 1450
The Bat! Pro 5.1.6.2
Helmut Hullen
Jun 9, 2012, 3:10:00 PM6/9/12
to
Hallo, Daniel,
Du meintest am 09.06.12:
Du meintest am 09.06.12:
>> Und sobald der Virus in der Datenbank ist, können Virenscanner ihn
>> entdecken, auch beim Rechner eines unbedarften Benutzers.
> Nur ist das für die Praxis vollkommen irrelevant. relevant sind die
> neuen Viren, die täglich zu Anwendung kommen und nicht die Viren anno
> 2010, die oft eh das neueste Sicherheitsupdate unmöglich macht.
Worauf stützt Du diese Behauptung? Hast Du belastbare Unterlagen, welche
>> entdecken, auch beim Rechner eines unbedarften Benutzers.
> Nur ist das für die Praxis vollkommen irrelevant. relevant sind die
> neuen Viren, die täglich zu Anwendung kommen und nicht die Viren anno
> 2010, die oft eh das neueste Sicherheitsupdate unmöglich macht.
Viren derzeit im Umlauf sind?
>>> Warum machst du das nicht gleich selbst? Ist ganz einfach! Benötigt
>>> kaum Fachwissen und sollte daher auch für dich umsetzbar sein!
>> Weil ich meinen Fähigkeiten misstraue. Ich hole lieber noch weitere
>> Meinungen ein und verlasse mich nicht einzig auf mich.
> Möglicherweise ist da ja für dich der beste Ansatz.
> Und mit "andere Meinungen" meinst du jetzt die Werbeslogans
> der Verkäufer, die ihr Schlangenöl los werden wollen und nicht die
> Meinung von Fachleuten wie Stefan?
Wenn Du mit Deinen Annahmen so oft voll daneben liegst, dann solltest Du
auch bei der Einschätzung des Verhaltens Deines Rechners Dich nicht
einzig auf Deine Einschätzung verlassen.
> Komischer Ansatz, echt!
Den komischen Ansatz hast Du frei erfunden; gebricht es Dir an Fakten?
Viele Gruesse!
Helmut
Ralph Angenendt
Jun 9, 2012, 3:25:56 PM6/9/12
to
Well, Helmut Hullen <Hel...@Hullen.de> wrote:
>>> Und sobald der Virus in der Datenbank ist, können Virenscanner ihn
>>> entdecken, auch beim Rechner eines unbedarften Benutzers.
Nur überleben die meisten Viren gar nicht so lange. Und schon wieder ist
>>> Und sobald der Virus in der Datenbank ist, können Virenscanner ihn
>>> entdecken, auch beim Rechner eines unbedarften Benutzers.
das Problem da, dass man sich durchaus was gefangen haben könnte, wenn
der Virenscanner nichts sagt. Und auch wenn er was sagt, dann hat man
eventuell was auf dem System, was gar nicht mehr funktioniert. Oder
zusätzlich etwas, was man nicht entdecken kann.
Und *wenn* man was auf dem System hat, dann nutzt der Virenscanner eh
nichts mehr, weil man dem System dann gar nicht mehr vertrauen kann.
>> Nur ist das für die Praxis vollkommen irrelevant. relevant sind die
>> neuen Viren, die täglich zu Anwendung kommen und nicht die Viren anno
>> 2010, die oft eh das neueste Sicherheitsupdate unmöglich macht.
>
> Worauf stützt Du diese Behauptung? Hast Du belastbare Unterlagen, welche
> Viren derzeit im Umlauf sind?
haben, woher soll man die bekommen, wenn täglich zwischen 30000 und
50000 neue Viren in Umlauf kommen?
Ralph
--
Als hätte es 100 Jahre Philosophie in Göttingen studiert ...
Daniel Kohl
Jun 9, 2012, 3:27:24 PM6/9/12
to
>
> Nein - Du gehst schon wieder von einer falschen Annahme aus.
>
> Wenn Du mit Deinen Annahmen so oft voll daneben liegst, dann solltest Du
> auch bei der Einschätzung des Verhaltens Deines Rechners Dich nicht
> einzig auf Deine Einschätzung verlassen.
>
>> Komischer Ansatz, echt!
>
> Den komischen Ansatz hast Du frei erfunden; gebricht es Dir an Fakten?
>
Tatsache, da brauche ich keine Statistik.
Ich glaube, dazu brauche ich keine Statistik, die täglichen Beispiel
sprechen für sich.
Wen du dich vor Viren schützen willst, musst du dich vor eben diesen
schützen können und das kann dein AV nun mal nicht.
Ansonsten ist die Infection nur ein Frage der Zeit.
Es ist doch wohl unstrittig, das täglich hunderte, wenn nicht tausende
neue Viren entsehen und in Umlauf kommen, oder?
Und wenn du dir die Statisken maö anschaust, was da so im Umlauf ist, zB
die der TU Wien,
wirst du sehen, dass der Großteil Varianten älterer Viren sind. Das in
Verbinung mit der miesen Trefferquote
der Heuiristik sollte doch selbst dir zu einem logischen Schluß verhelfen.
Und nein, ich verlasse mich nicht auf mich selbst, sondern hole mir Rat
von Leuten die sich
damit auskennen, wenn ich nicht weiter weis, bzw Bilde mich weiter und
nehme Rat an.
Solltest du auch mal probieren!
PS: Warum fall ich eigentlich imemr auf dieses Getrolle herein?
Daniel Kohl
Jun 9, 2012, 3:34:38 PM6/9/12
to
Helmut Hullen
Jun 9, 2012, 3:57:00 PM6/9/12
to
Hallo, Ralph,
Du meintest am 09.06.12:
>>>> Und sobald der Virus in der Datenbank ist, können Virenscanner ihn
>>>> entdecken, auch beim Rechner eines unbedarften Benutzers.
> Nur überleben die meisten Viren gar nicht so lange. Und schon wieder
> ist das Problem da, dass man sich durchaus was gefangen haben könnte,
> wenn der Virenscanner nichts sagt. Und auch wenn er was sagt, dann
> hat man eventuell was auf dem System, was gar nicht mehr
> funktioniert. Oder zusätzlich etwas, was man nicht entdecken kann.
100-prozentige Sicherheit gibt es nicht. Bei keinem Verfahren.
> Und *wenn* man was auf dem System hat, dann nutzt der Virenscanner eh
> nichts mehr, weil man dem System dann gar nicht mehr vertrauen kann.
Dem System kann ich nie trauen.
Auf einem meiner Rechner liegen etwa 20 Viren - na und?
Ein anderes habe ich gerade frisch aufgesetzt - ist es heute "sauber"?
Ist es auch morgen noch "sauber"?
>>> Nur ist das für die Praxis vollkommen irrelevant. relevant sind die
>>> neuen Viren, die täglich zu Anwendung kommen und nicht die Viren
>>> anno 2010, die oft eh das neueste Sicherheitsupdate unmöglich
>>> macht.
>> Worauf stützt Du diese Behauptung? Hast Du belastbare Unterlagen,
>> welche Viren derzeit im Umlauf sind?
> Wie soll man das haben bei Viren, die eine Lebenszeit von ca. 4
> Stunden haben, woher soll man die bekommen, wenn täglich zwischen
> 30000 und 50000 neue Viren in Umlauf kommen?
Woher hast Du die Zahl von "zwischen 30000 und 50000 neue Viren"?
Ansonsten: wieso bekomme ich davon fast nichts ab? Das letzte Paket habe
ich vor mehr als 1 Woche bekommen - hat man mich vergessen?
Viele Gruesse!
Helmut
Du meintest am 09.06.12:
>>>> Und sobald der Virus in der Datenbank ist, können Virenscanner ihn
>>>> entdecken, auch beim Rechner eines unbedarften Benutzers.
> Nur überleben die meisten Viren gar nicht so lange. Und schon wieder
> ist das Problem da, dass man sich durchaus was gefangen haben könnte,
> wenn der Virenscanner nichts sagt. Und auch wenn er was sagt, dann
> hat man eventuell was auf dem System, was gar nicht mehr
> funktioniert. Oder zusätzlich etwas, was man nicht entdecken kann.
> Und *wenn* man was auf dem System hat, dann nutzt der Virenscanner eh
> nichts mehr, weil man dem System dann gar nicht mehr vertrauen kann.
Auf einem meiner Rechner liegen etwa 20 Viren - na und?
Ein anderes habe ich gerade frisch aufgesetzt - ist es heute "sauber"?
Ist es auch morgen noch "sauber"?
>>> Nur ist das für die Praxis vollkommen irrelevant. relevant sind die
>>> neuen Viren, die täglich zu Anwendung kommen und nicht die Viren
>>> anno 2010, die oft eh das neueste Sicherheitsupdate unmöglich
>>> macht.
>> Worauf stützt Du diese Behauptung? Hast Du belastbare Unterlagen,
>> welche Viren derzeit im Umlauf sind?
> Wie soll man das haben bei Viren, die eine Lebenszeit von ca. 4
> Stunden haben, woher soll man die bekommen, wenn täglich zwischen
> 30000 und 50000 neue Viren in Umlauf kommen?
Ansonsten: wieso bekomme ich davon fast nichts ab? Das letzte Paket habe
ich vor mehr als 1 Woche bekommen - hat man mich vergessen?
Viele Gruesse!
Helmut
It is loading more messages.
0 new messages