Nach Anmeldung direkt in Skript (Linux)

[pGRoBkiLL]

Hi,
folgende Aufgabe:

Ich logge mich per Konsole auf meinem Linux-Rechner ein (kein X). Danach will ich, dass ich direkt in einem Skript lande, welches mir nur bestimmte Befehle erlaubt z.B.

(1) Führe Skript B aus
(2) Starte vi
(3) Zeige Prozesse an

Ich drücke also 1 und es wird Skript B ausgeführt. Danach lande ich wieder im Menü. Dann drück ich 2 und es wird z.B. vi ausgeführt. Das "Menü-Skript" darf sich nicht von mir beenden lassen.

Die Sache mit dem Skript direkt nach dem Login ist nur eine Idee von mir. Grundsätzlich will ich einfach nur, dass der User der sich anmeldet nur bestimmte Funktionen ausführen darf z.B. kein ls, mkdir, cd usw. sondern nur von mir definierte Kommandos.

Hat jemand Lösungsvorschläge hierfür? Oder zumindest ne Idee wonach ich schauen muss?

Danke!

 

[astur]

Wenn du ein bisschen programmieren kannst (absolut grundlegendes C reicht aus), kannst du dir einfach deine eigene "Shell" bauen und die beim entsprechenden Benutzer in der /etc/passwd eintragen. Das habe ich mal bei meiner fritzbox gemacht, um via putty aus dem Uninetz darüber zu tunneln. Dafür musste man sich auch auf der box anmelden, und ich wollte aus nachvollziehbaren Gründen meinen Kommilitonen nicht unbedingt einen brauchbaren Account auf meinem Router geben. Also einfach ein kleines Programm geschrieben, das eine Anleitung anzeigt und sonst genau nichts macht.

Für dich würde das bedeuten, dass du eine kleine Konsolenanwendung baust, die (netterweise) die erlaubten Befehle anzeigt, eine Eingabe abwartet und dann den entsprechenden Befehl ausführt. Wenn du keine Ahnug von Programmieren hast, wäre das ein toller Einstieg und lässt sich (wirklich absolut grundlegend) mit Befehlen wie cin, cout und exec lösen.

 

[Starfire]

BÄM! kanonen auf spatzen

wozu gibts denn die datei .profile?
http://rowa.giso.de/german/dotfiles.html

und userrechte kannste so setzen, dass er kein ls mkdir etc ausführen darf, auch wenn ers aus dem skript schafft und das logoff ausschalten kann.

 

[astur]

BÄM! kanonen auf spatzen

Wenn man von nix außer Kanonen ne Ahnung hat...

 

[HERR 2FICKENDEHUNDE]

wozu das rad neu erfinden, wenn es bereits eins gibt?

.profile ist schon vollkommen in ordnung, alternativ auch die datei .bashrc.

du musst dir halt ein skript bauen, dass die gewünschten funktionen anbietet, mit bash wäre die case anweisung zb einfaches mittel, das auswahlmenu umzusetzen u. sinnvoller weise solltes du am anfang SIG signale abfangen, also strg+c oder strg+d damit das skript vom angemeldeten user nicht abgebrochen werden kann.

wenn du das fertig hast musst du dieses nun in der .bashrc des users mit exec ausführen. wenn das programm beendet wurde, wird exec auch die shell beenden und eine login shell erscheint.

alles im allen eigentlich recht simpel und im internet sind sicher jede menge beispiele dazu.

ich erkenne keinen grund sich dafür irgend neues werkzeug zu bauen, es ist dafür alles schon da. aber warum einfach wenns auch schwer geht, nicht?

 

[astur]

du musst dir halt ein skript bauen, dass die gewünschten funktionen anbietet, mit bash wäre die case anweisung zb einfaches mittel, das auswahlmenu umzusetzen u. sinnvoller weise solltes du am anfang SIG signale abfangen, also strg+c oder strg+d damit das skript vom angemeldeten user nicht abgebrochen werden kann.

wenn du das fertig hast musst du dieses nun in der .bashrc des users mit exec ausführen. wenn das programm beendet wurde, wird exec auch die shell beenden und eine login shell erscheint.

[...]

ich erkenne keinen grund sich dafür irgend neues werkzeug zu bauen, es ist dafür alles schon da. aber warum einfach wenns auch schwer geht, nicht?

Nichts für ungut, aber ob ich mir jetzt in shellscript was baue oder ein konsolenbasiertes C-Programm bastel gibt sich nicht wirklich viel, Compilen mal außen vor. Mein Hass auf Shellscript mag da natürlich auch mit rein spielen, aber für so absoluten Lowlevel-Kram ist C auch wirklich nicht schwer. Und ob ich das eine in Datei X einbinde oder das andere in Datei Y ist jetzt auch nicht so der Unterschied.

Wie gesagt, ich beschäftige mich damit nicht großartig, und dass man als Konsolenguru eine Lösung der anderen vorzieht - gerne. Davon abgesehen: Wenn beides funktioniert und der Aufwand ähnlich ist, freuen sich doch alle.

 

[HERR 2FICKENDEHUNDE]

Nichts für ungut, aber ob ich mir jetzt in shellscript was baue oder ein konsolenbasiertes C-Programm bastel gibt sich nicht wirklich viel, Compilen mal außen vor. Mein Hass auf Shellscript mag da natürlich auch mit rein spielen, aber für so absoluten Lowlevel-Kram ist C auch wirklich nicht schwer. Und ob ich das eine in Datei X einbinde oder das andere in Datei Y ist jetzt auch nicht so der Unterschied.

Wie gesagt, ich beschäftige mich damit nicht großartig, und dass man als Konsolenguru eine Lösung der anderen vorzieht - gerne. Davon abgesehen: Wenn beides funktioniert und der Aufwand ähnlich ist, freuen sich doch alle.

woher weisst du denn, dass der threadersteller über ausreichend C kenntnisse verfügt? schön für dich, dass du es kannst aber ich denke mal, dass dein vorschlag wenig bis überhaupt nicht hilfreich ist. ausserdem sind boardmittel für fremdzugriffe grundsätzlich vorzuziehen, denn wenn ich es richtig verstehe, will er anderen den zugang ermöglichen und dann sind solche frickellösung wie du sie vorschlägst allein schon aus sicherheitsgründen überhaupt nicht zu empfehlen. es sei denn du weisst was du tust und den eindruck vermittelst du hier, zumindest was linux angeht, nicht gerade...

 

[astur]

woher weisst du denn, dass der threadersteller über ausreichend C kenntnisse verfügt? schön für dich, dass du es kannst aber ich denke mal, dass dein vorschlag wenig bis überhaupt nicht hilfreich ist. ausserdem sind boardmittel für fremdzugriffe grundsätzlich vorzuziehen, denn wenn ich es richtig verstehe, will er anderen den zugang ermöglichen und dann sind solche frickellösung wie du sie vorschlägst allein schon aus sicherheitsgründen überhaupt nicht zu empfehlen. es sei denn du weisst was du tust und den eindruck vermittelst du hier, zumindest was linux angeht, nicht gerade...

Aber skripten kann er perfekt? Sehe ich auch nirgends, daher dito an deine Lösung. Frickelig ist meine Lösung im Übrigen genauso wie deine, der Programmablauf ist ziemlich identisch. Das gleiche gilt für Sicherheitsfragen - ob ich den vorgefertigten Befehl via backtick im skript oder exec im programm aufrufe, ist mal vollkommen egal.

Aber hey, lass uns Lösungsvorschläge für beschissen erklären, bevor wir überhaupt wissen, was der TE kann/will/braucht. Ist immer ein guter Anfang für ne gesunde Diskussionskultur.

Aber viel Spaß noch, ich bin hier dann mal raus und überlasse den lauteren Stimmen das Feld.

 

[pGRoBkiLL]

Danke erstmal für die Antworten. Ich muss sagen, C kann ich besser als Scripting aber vom Aufwand her nimmt sich beides nicht viel. Das wichtigste für mich ist, dass der User auf keinen Fall aus dem Auswahlmenü kommt. Ich weiß nicht ob ich das zu 100% gewährleisten kann. Ich denke eher nicht und wenn er es irgendwann mal doch schaffen sollte, dann darf er auf keinen Fall eine Shell vorfinden wo alle möglichen Befehle erlaubt sind.

Was haltet ihr davon, dem User eine chroot-Umgebung zu erstellen wo nur die erlaubten Skripte drin sind?

 

[HERR 2FICKENDEHUNDE]

chroot ist kein sicherheitsfeature. chroot kann nur von root ausgeführt werden, damit kann er dann mounten und bye bye sicherheit.

wie gesagt, aus dem auswahlmenu kommt er nicht raus, wenn du die entsprechenden Signale abfängst. dazu gibt es in bash die funtion trap.

dein menu geht mit case, zb so

#!/bin/bash
#
# readkey - Einfaches Menü mit read und case erstellen.

# strg+c abfangen
#andere signale abfangen: http://www.cs.pitt.edu/~alanjawi/cs449/code/shell/UnixSignals.htm
trap "" INT 

# Bildschirm leeren
clear
# Menü und read
echo -e "Drücken Sie die entsprechende Taste für Ihre Auswahl.\n"
echo -e "Dein skript1\t\t1"
echo -e "dein skript2\t\t2"
echo -e "Hilfe\t\th"
echo -e "Beenden\t\tb \n"
read -n 1 TASTE

# Auswahl anzeigen
case $TASTE in
	1)  /usr/local/bin/skript1.sh
            ;;
	2)  /usr/local/bin/skript2.sh
	    ;;
	h|H)
	    # Gross/Kleinschreibung berücksichtigen
	    echo -e "\nHilfetext"
	    ;;
	b|B)
	    # Gross/Kleinschreibung berücksichtigen
	    echo -e "\nThe End"
            exit
	    ;;
	*)  echo -e "\nEs wurde keine Auswahl getroffen.";;
esac

erklärungen:
http://linuxseiten.kg-it.de/index.php?index=bash_Die_case-Anweisung

wenn du dazu sogar noch ein grafisches menu haben willst schau dir dialog an. man dialog.

dann packst du dieses skript in die .bashrc des benutzers und führst es dort mit exec aus.

näheres zu exec gibts mit man exec.

wenn der benutzer nun eine anmeldung erfolgreich durchgeführt hat, startet exec dein skript, exec macht keinen fork, sondern ersetzt das Prozessabbild Deines aufrufenden Programms durch das des per exec gestarteten. er kann dann die sachen, die du ihm zur verfügung stellst, ausführen. er kann kein strg+c,z,d usw, weil du diese signale abgefangen hast. wird das skript beendet, wird auch die der exec prozess beendet und damit die shell des users. es erscheint die login shell. das ist eine besonderheit von exec und genau für solche einsatzzwecke gedacht.

und jetzt will ich mal rein interesse halber sehen, wie sowas mit gleichem aufwand in c aussehen würde...

 

[pGRoBkiLL]

Ich glaub, der Umweg über die .bashrc ist nicht nötig. Ich habe jetzt ein Auswahlskript geschrieben

echo "Choose your action:";
select choice in action1 action2 action3

do
   if [ $choice = action1 ]
   then
       echo "action1"
   fi

if [ $choice = action2 ]
   then
       echo "action2"
   fi
done

Dieses Skript hab ich dem User als Login-Shell in der /etc/passwd eingetragen und es scheint zu funktionieren. User meldet sich an, kommt in mein Skript. Versucht er, es zu beenden landet er wieder beim Login-Prompt.

 

[pGRoBkiLL]

Hm weitere Tests haben ergeben, dass es wohl nicht so einfach ist. Das stupide Ausgeben von Text geht ja noch aber irgendwelche Skripte ausführen funzt dann nicht mehr leicht oder ich hab was übersehen. Ich bleibe dran!

 

[drwilly]

probier vor allem mal aus, ob du mit 'ssh foobar /bin/bash' auch in deinem skript landest.