Autor Thema: Script verschlüsseln  (Gelesen 4379 mal)

Offline KrustyDerClown

  • Unix Rookie
  • *
  • Beiträge: 3
    • Profil anzeigen
Script verschlüsseln
« am: 20. September 2012, 23:10:57 »
Hallo Zusammen,

ich will das ein bestimmter Benutzer auf meinem Unix System ein Script von einem anderen Benutzer ausführen darf.

Er soll das Script allerdings nur ausführen dürfen - nicht lesen dürfen (steht ein Passwort drin).

Wenn ich mich richtig informiert habe müsste ich hierfür das Script kompilieren. Ist das korrekt? Ist das mit "normalen" Board Mitteln möglich? (Sun Solaris System)

Die Alternative wäre auch das Passwort im Script zu verschlüsseln. Dann wäre es auch OK, wenn der Benutzer Lese Rechte erhalten würde. Ist das möglich, dass man ein Passwort verschüsselt in einem Script?

Vielen Dank voarb.

Viele Grüße
Oliver

unixforum.net - Der Treffpunkt für UNIX-Fans

Script verschlüsseln
« am: 20. September 2012, 23:10:57 »

oreissig

  • Gast
Re: Script verschlüsseln
« Antwort #1 am: 21. September 2012, 01:24:18 »
du kannst ihm leserechte auf das skript entziehen
alles andere ist security by obscurity. womit sollte das skript denn verschlüsselt sein, wenn der nutzer es trotzdem ausführen können soll? dafür muss er ja auf den schlüssel zugreifen können, aber dann könnte er sichs auch selbst wieder entschlüsseln

Offline Ten Little Indyans

  • Unix Bachelor
  • ***
  • Beiträge: 185
    • Profil anzeigen
Re: Script verschlüsseln
« Antwort #2 am: 21. September 2012, 13:17:29 »
du kannst ihm leserechte auf das skript entziehen

Das geht nur bei "echten" Executables.  Ein Skript muss immer gelesen werden können um es auszuführen.

Sieht der Kernel eine Zeile wie #!/bin/sh dann ruft er letztlich nur diesen Interpreter auf und übergibt ihm die Skriptdatei als Parameter.  Der als gewöhnlicher User laufende sh-Prozess muss die Datei dann ganz normal öffnen und lesen um sie auszuführen.

oreissig

  • Gast
Re: Script verschlüsseln
« Antwort #3 am: 21. September 2012, 15:20:58 »
dann sollte sich doch mit setuid was drehen lassen, sodass der eigentlich ausführende keine leseberechtigung braucht, oder?

Offline Ten Little Indyans

  • Unix Bachelor
  • ***
  • Beiträge: 185
    • Profil anzeigen
Re: Script verschlüsseln
« Antwort #4 am: 21. September 2012, 16:31:34 »
Es gibt ganze Romane darüber warum setuid-Skripte keine gute Idee sind.

Soweit ich weiss verbietet Linux das auch grundsätzlich und bei vielen anderen Unixen geht es nur mit entsprechend alten Versionen (z.B. AIX < 3.2 oder SunOS 4).

Zitat von: Wikipedia
Auf den meisten Systemen funktioniert dies nur für ausführbare Binärdateien, nicht jedoch für interpretierte Scripts.
http://de.wikipedia.org/wiki/Setuid

Sofern sudo vorhanden ist könnte es damit aber funktionieren.

Offline dominik_bsl

  • Unix Junior
  • **
  • Beiträge: 57
    • Profil anzeigen
Re: Script verschlüsseln
« Antwort #5 am: 26. September 2012, 16:37:55 »
Naja ich würde da folgendes machen:

Permissions auf 0700 für das Script mit Ownership des auszuführenden Users mit trap "" 2 3 am Anfang des Scripts sodass kein 'ctrl-c' möglich ist und dann jenes Script eine 0600 Datei mit Ownership des auszuführenden Users einlesen lassen welche das Passwort enthält. Auszuführen ist das ganze dann mittels 'sudo' welcher selbstverständlich nur die Ausführung des Scripts zulässt.

Gruss
Dominik

AndreasF

  • Gast
Re: Script verschlüsseln
« Antwort #6 am: 26. September 2012, 19:01:24 »
Vielleicht ist folgendes auch vollkommenere Unsinn:
Wenn auf der Maschine ein Webserver läuft das Script so ablegen, dass es nur der Benutzer unter dem der Webserver läuft lesen darf.
Dann ein Script auf dem Webserver ablegen (einfaches PHP zb http://www.php.net/manual/en/function.exec.php) welches wenn aufgerufen das gewünschte Script ausführt. Den Zugang zu diesem "Metascript" könnt ihr dann je nach bedarf über htaccess oder irgendwas in das PHP-Skript eingebaute sichern.

linuxdomination

  • Gast
Re: Script verschlüsseln
« Antwort #7 am: 29. September 2012, 17:42:17 »
http://www.datsi.fi.upm.es/~frosal/

geht mir zwar am sack, aber wers braucht...