Jump to content

paulx

Abgemeldet
  • Gesamte Inhalte

    32
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

10 Neutral

1 Benutzer folgt diesem Benutzer

Profile Fields

  • Member Title
    Gast
  1. Ich habe eine eigene Software mit Hilfe der in Windows XP enthaltenen iexpress.exe gepackt, diese will ich im Internet veröffentlichen. Nun gibt es die Möglichkeit, mit Hilfe der legalen Software Ressource Hacker dieses selbstextrahierende Archiv zu manipulieren. Dabei kann man z. B. die Versionsinformationen ändern, also anpassen für die eigene Software und unnötige Teile, etwa dieses kleine Video, rausnehmen. Das hat den Vorteil, dass sich dann die Versionsinformationen auf die eigene Software beziehen und dass das Archiv dann von der Dateigröße her kleiner ist. Ich stelle mir das so vor: Ich habe die Software mit der iexpress.exe erstellt, wenn ich sie dekompiliere, ist das rechtlich erlaubt, da ich ja nicht die iexpress.exe selbst, sondern deren "Kompilat" dekompiliere. Ich habe also einfach die iexpress.exe als einen Compiler betrachtet, und eine mit einem Compiler von Hersteller XY kompilierte Software darf ich ja auch dekompilieren und veröffentlichen, ohne Hersteller XY nach Erlaubnis zu fragen, wenn ich die Software selbst entwickelt habe. Ist diese Rechtsauffassung korrekt?
  2. So, ich habe die Richtlinie jetzt umgesetzt, läuft wie gewünscht, danke für den guten Tipp!
  3. Ich habe mir jetzt mal das mit den Gruppenrichtlinien grob angesehen, ich denke, damit müsste ich es hinkriegen. Das Problem mit der Änderung des Besitzers sehe ich in diesem Fall nicht, obwohl ich deine Argumente, die dagegen sprechen, durchaus nachvollziehen kann. Aber hier geht es um eine Umgebung, in der Quotas und servergespeicherte Profile keine Rolle spielen. Aber es ist schon richtig, dass es für das angesprochene Ziel so nicht wirklich was bringt.
  4. Nur ich kann dem Benutzer ja nicht den Schreibzugriff auf das eigene Benutzerprofil sperren. Das ist mir bekannt, deshalb fragte ich, wie man es ändern kann. Bei Benutzern mit Administratorrechten kann man es nämlich ändern, nur bei Benutzern mit eingeschränkten Rechten habe ich bisher nichts gefunden. Wenn man in den erweiterten Sicherheitseinstellungen eines Ordners in die Registerkarte Besitzer klickt, dann kann man hier, wenn man als Administrator eingeloggt ist, Administratoren anklicken, dann wird der Besitzer des Ordners auf "Administratoren" geändert. Wenn man zusätzlich das Häkchen bei "Besitzer der Objekte und untergeordneten Container ersetzen" anklickt, überträgt sich diese Einstellung in alle Unterordner und Dateien. Deinen Tipp mit den Gruppenrichtlinien schaue ich mir mal an.
  5. Ich habe auf einem Windows XP Pro SP2- System folgendes Problem: Ich habe einen eingeschränkten Benutzer erstellt, nennen wir ihn Test. Bei diesem habe ich in dessen Benutzerkonto die Rechte Ordner durchsuchen/Datei ausführen, Berechtigungen ändern und Besitzrechte übernehmen aus den erweiterten NTFS- Sicherheitseinstellungen gestrichen. Zudem habe ich den Besitzer für das Benutzerprofil auf Administratoren gesetzt. Diese Einstellungen habe ich in alle untergeordneten Objekte übertragen. Das hat auch alles wunderbar geklappt. Nur dann habe ich mal den Test gemacht und eine ausführbare Datei aus dem Internet geladen und im Benutzerprofil gespeichert. Die habe ich dann gestartet, es erscheint wie gewünscht die Fehlermeldung "Auf das angegebene Gerät, bzw. den Pfad oder die Datei kann nicht zugegriffen werden. Sie verfügen evtl. nicht über ausreichende Berechtigungen, um auf das Element zugreifen zu können.". Dann habe ich aber mal als Benutzer Test die Sicherheitseinstellungen der Datei aufgerufen und festgestellt, dass ich die Sicherheitsoptionen ändern konnte sprich Vollzugriff erlauben konnte. Beim Schauen in die erweiterten Rechte stellte ich schließlich den Grund fest: Die Datei hatte als Besitzer den Benutzer "Test", so erklärte sich dann, warum ich die Sicherheitsrechte ändern konnte, ohne mich als Admin anzumelden. Nachdem ich diese Rechte dann änderte sprich Vollzugriff erlaubte, konnte ich die Datei problemlos ausführen. Das ist nun etwas, was ich dem Benutzer eigentlich verbieten wollte. Kann mir jemand sagen, wie ich es ihm verbieten kann?
  6. Ich habe es nun mit SetACL ausprobiert, komme aber nicht so richtig voran. Ich habe zwar den grundlegenden Aufbau durch http://setacl.sourceforge.net/html/examples.html verstanden, aber wie ich Verweigerungsrechte setze, habe ich noch nicht verstanden. Kann mir das jemand erklären? Bitte nicht lachen, ich bin SetACL- Anfänger.
  7. Vielen Dank für eure Antworten und sorry für meine späte Antwort. Ich werde es mit SetACL ausprobieren.
  8. Ich würde gerne ein Skript schreiben, das in einem Ordner oder einem Laufwerk folgende NTFS- Berechtigung für einen bestimmten Benutzer vergibt: Alles außer folgendem: Ordner durchsuchen/ Datei ausführen, Berechtigungen ändern, Besitzrechte Übernehmen. Es handelt sich um Optionen, die man nur über die erweiterten Sicherheitseinstellungen bekommt. Damit soll erreicht werden, dass der Benutzer etwa exe- Dateien speichern kann, sie jedoch nicht ausführen kann. Wenn in einem Ordner das Recht Ordner durchsuchen/ Datei ausführen für einen Benutzer deaktiviert wurde, kann eine exe- Datei, die in diesem Ordner gespeichert wird, von diesem Benutzer nicht ausgeführt werden. Das Wegnehmen der zwei weiteren Rechte soll dazu führen, dass dies nicht rückgängig gemacht werden kann. Leider geht das nicht mit cacls. Könnt ihr mir ein anderes Tool nennen, mit dem ich das durchführen kann? PS: Ich bin mir darüber bewusst, dass diese Sicherheitsmaßnahme allein nicht ausreicht.
  9. Allerdings verstehe ich auch nicht ganz, was an der /savecred- Option so völlig sinnlos sein soll. Dass das nicht so gelungen ist, dass man die Passwörter nicht mit einer klar ersichtlichen Option wieder löschen kann und es Missbrauch ermöglicht, das ist klar. Aber völlig sinnlos ist es deshalb trotzdem nicht. Ich habe z. B. ein Benutzerkonto erstellt, von dem man sagen kann, dass es sehr, sehr restriktiv konfiguriert ist. Damit surfe ich. Mehr geht damit auch nicht. Ich logge mich mit einem standardmäßig konfigurierten eingeschränkten Benutzerkonto ein und starte meinen Browser mit diesem sehr restriktiv konfigurierten Benutzerkonto. Und zwar mit einer runas /savecred- Verknüpfung. Gut, in diesem Benutzerkonto kann man dadurch Programme mit diesem restriktiv konfigurierten Benutzer starten, ohne das Passwort dieses Benutzers zu wissen. Aber das ist ja nicht so direkt schlimm, weil man dadurch die Rechte nicht erhöhen kann.
  10. Wenn das tatsächlich unter keinen Umständen legal sein sollte, könnte man die Lizenzpolitik von MS glatt als äußerst dumm durchgehen lassen. Schließlich hat MS keinen Nachteil davon, wenn man auf seinem XP- System eine Windows 2000- Systemdatei verwendet. Also kann man diese Maßnahme klar in die Kategorie "Probleme schaffen, ohne irgendwelche Probleme zu lösen", einordnen. Ich glaube allerdings nicht, dass das illegal ist. Man kann völlig legal etwa die msconfig.exe aus XP über das Internet für Win 2000- User verbreiten, wie man unter http://download.winhelpline.info/dlm_download.php?id=329 sieht. Ich würde kaum annehmen, dass die Sache umgekehrt illegal wäre.
  11. Die runas.exe von Windows XP durch die von Windows 2000 ersetzen. Das funktionierte bei meinem Windows XP Pro SP2- System. Die Datei stammte von einem Windows 2000 SP4- System. Ich weiß allerdings nicht, unter welchen Umständen das Kopieren einer Windows 2000- Systemdatei auf ein XP- System legal ist.
  12. Was dagegen spricht, dem Benutzer ein Passwort zu geben? Ist doch eigentlich klar. Es bringt sicherheitsmäßig nichts, dem User ein Passwort zu geben, wie ich bereits schrieb. Und es erhöht den Aufwand. OK, nicht stark, aber ein bißchen mehr Aufwand für ein quasi gleiches Ergebnis ist eben insgesamt schlecht. Abgesehen davon, dass der User dann als Admin surfen würde. Ob das in irgendwelchen Büchern drinsteht, dass man das so machen soll, ist mir nicht so wichtig. Bzw., wenn es überall drin steht, senkt es sogar die Glaubwürdigkeit. Denn wenn alle etwas schreiben und Kritiker zurechtgewiesen werden, kommt leicht der Verdacht auf, dass ein gewisser Teil das nur schreibt, um nicht das eigene Ansehen zu riskieren, nicht, weil sie das wirklich meinen. Aber ich habe keine Lust mehr auf die Diskussion. Ich habe sie ohnehin nur geführt, weil ich lernen wollte, warum dieses Sicherheitskonzept schlecht ist. Aber das werde ich hier wohl nicht lernen. Ich übernehme nicht einfach Meinungen, wenn ich sie nicht nachvollziehen kann, auch wenn es Mehrheitsmeinungen sind. Warum? Ich kann Meinungen nicht damit begründen, dass das allgemeine Meinung ist. Ich muss Argumente liefern. Und zwar Argumente, die derjenige nachvollziehen kann, auch wenn er wenig Ahnung von der Sache hat. Und dafür ist es zunächstmal erforderlich, dass ich die Argumente richtig finde. Ich kann ja keine Argumente bringen, an deren Relevanz ich selbst zweifle. Zu dem Porsche: Man versucht, Wünsche zu erfüllen. Wenn man es nicht kann oder der Aufwand zu hoch wäre, macht man es eben nicht, so wie beim Porsche.
  13. Warum redet ihr eigentlich immer um den heißen Brei herum? Warum sagt ihr nicht einfach, warum dieses Sicherheitskonzept schlecht ist sprich warum Viren aus dem Browser heraus in der von mir beschriebenen Konfiguration leichter starten als wenn man sich direkt als Benutzer einloggt. Dass man sich mit dem Setzen eines Passworts für einen ziemlich entrechteten Benutzer nicht vor physischen Zugriffen auf das System schützen kann, sollte doch eigentlich bekannt sein. Für den Hinweis mit der dropmyrights.msi: Danke. Ich habe das Problem inzwischen allerdings selbst gelöst: Mit der /savecred- Option des runas- Befehls.
  14. Entschuldigung für meine späte Antwort. 1. Ist es nicht klar, dass ein Browser, der im Kontext eines einfachen Benutzers läuft, sicherer ist als ein Browser, der im Kontext des Administrators läuft und es somit für einen Benutzer, der als Admin arbeitet, sinnvoll ist, den Browser als Benutzer zu starten? Das Loch mit dem eingeschränkten Benutzer ohne Passwort ist ja wohl lächerlich. Schon mal was von Bart PE gehört? Da kann das Passwort noch so kompliziert sein, damit kommt jeder, der physischen Zugriff auf den Rechner hat, zumindest bei den meisten Rechnern ohne Probleme rein. Wer sich vor so etwas schützen will, muss sein Dateisystem so oder so verschlüsseln oder mit Festplatte im Wechselrahmen arbeiten. Benutzer- Passwörter als Schutz vor physischem Zugriff auf das System sind lächerlich, insbesondere, wenn es um eingeschränkte Konten geht. Ich will den bösen Menschen sehen, der mit einer Bart PE- CD in der Tasche an einem gesetzten Passwort für ein eingeschränktes Konto verzweifelt. 2. Ist es nicht klar, dass es Leute gibt, bei denen es schwerer fällt, sie davon zu überzeugen, sich mit Benutzerrechten einzuloggen als sie davon zu überzeugen, ihren Browser automatisch mit Benutzerrechten starten zu lassen? Es gibt Leute, denen kann man Benutzerrechte einrichten, dann installieren sie irgendein Programm, das nur mit Adminrechten geht, und schon arbeiten sie wieder als Admin. 3. Ich brauche keine Nachhilfe in Sachen Bildung von Sicherheitskonzepten. Was meint ihr, warum ich mich jahrelang mit dem Thema Sicherheit beschäftigt habe? Wenn ich nur die Ideen, die andere an mich herantragen, kopieren wollte, hätte ich mir das sparen können. Nein, viel mehr: Damit Malware nicht ohne weiteres ausgeführt werden kann. Schon mal was von der erweiterten NTFS- Option "Ordner durchsuchen/ Datei ausführen" gehört? Ist die für einen Ordner nicht gesetzt, können in diesem Ordner gespeicherte Dateien von diesem Benutzer nicht ausgeführt werden (.exe, .pif, .cmd, .bat). Klar, Dateien für den Windows Scripting Host, den Windows Installer, Java- Programme und ähnliches oder sowas können immernoch ausgeführt werden. Aber die kann man ja auch sperren, indem man die jeweiligen Dateien wie etwa den Windows Scripting Host für den jeweiligen Benutzer sperrt. Auf diese Weise ist es leicht möglich, dieses Ausführungsrecht für jeden beschreibbaren Ordner zu sperren. Die Hauptvorteile an dem Konzept sind also: 1. Es fällt oft nicht so schwer, Leute davon zu überzeugen. 2. Die Leute werden seltener rückfällig. 3. Es ist deutlich einfacher verwendbar, da man bei Programmen, die für den Einsatz durch eingeschränkte Benutzer nicht ausgelegt sind, keine Probleme einhandelt. Ich selbst krieg die damit mitunter verbundene komplizierte und zeitaufwändige Arbeit mit Regmon, Filemon usw. schon hin, aber bei einem normalen Benutzer kann man das nicht erwarten.
  15. Ich habe folgendes Problem: Ich würde gerne auf einem Windows XP SP2- System, dessen Benutzer sich als Administrator anmeldet, den Browser als Benutzer starten lassen, ohne dass sich für den Benutzer etwas verändert. Es geht um einen Benutzer, der Veränderungen überhaupt nicht haben kann. Das Grundkonzept stand sofort: runas /user:<Benutzername> <Programmpfad> als Verknüpfung. Um das machen zu können, habe ich zunächstmal mit Hilfe der gpedit.msc die Option, dass beim runas- Befehl ein Kennwort zwangsläufig notwendig ist, deaktiviert. (Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsptionen- Konten: Lokale Kontenverwendung von leeren Kennwörtern auf Konsolenanmeldung beschränken- Deaktiviert). Dann hat es im Grunde geklappt, nur es wurde noch die Eingabeaufforderung angezeigt, bei der man dann die Eingabetaste drücken muss. Das ist etwas, was dieser Benutzer nicht akzeptieren kann. Deshalb meine Frage: Gibt es eine Möglichkeit, dafür zu sorgen, dass diese Eingabeaufforderung nicht angezeigt wird und das Programm direkt mit dem entsprechenden Benutzer gestartet wird?
×
×
  • Neu erstellen...