2. Root account - was muss ich beachten?

[bombaldi]

Hallo liebe Community,

also mein Problem ist folgendes wir arbeiten momentan an einem grösseren Projekt im Team und da mein Freund schon erheblich mehr über unix / server weiss als ich möchte ich ihm auch einen Root account auf dem Server einrichten.

Jetzt habe ich da aber bedenken, ich bin teilweise vielleicht ein zu paranoider Mensch aber aufjedenfall habe ich angst er könnte evtl eine backdoor oder Sachen dort machen die ich nicht möchte, wie zb zusätzliche Services installieren oder einfach mal meine Sqldb klauen oder ähnliches.

Nun die Frage:
Wie kann ich dagegen vorgehen? Am besten wäre so etwas wie die .bash_history die mir jeden cmd den er ausführt protokolliert, allerdings kann er die ja leicht modifizieren oder löschen da er ja eben auch root user ist.

Eine andere Frage wäre ob ich den account irgendwie ganz explizit stück für stück nur einzelne Sachen erlauben darf

Sinnvoll wäre sicher soetwas wie von allen dateien eine Database mit jeweiligem md5 hash anzulegen, nur weiss ich leider nicht wie ich sowas realisieren könnte...

Ich hoffe mal ihr habt noch gute ansätze was man in so einer Situation tuen kann...

lg
tom

[flo]

entweder Du vertraust ihm, oder Du vertraust ihm nicht, eine andere (sichere) Möglichkeit gibt es nicht.

Ansatzpunkte wären aber:

- braucht der zweite Account Root-Rechte?
- Müsst Ihr überhaupt als root arbeiten?
- Prüfsummen per AIDE oder ähnlichem Tool
- rkhunter einsetzen
- System überwachen - netstat o.ä., von extern z.B. per nmap

Die Überwachungsgeschichten sind allerdings relativ sinnlos, wenn der andere freiwillig von Dir Admin-rechte bekommt und sich dazu auch noch besser auskennt als Du - will sagen: Keine wirkliche Chance ...

[bombaldi]

ach komm ;)

für jedes Problem gibt es eine Lösung ich könnte mir doch zb die ausgabe von .bash_history automatisch auf einen entfernten Server senden auf dem der Freund dann keinen Zugriff hat...

Und naja vielleicht reicht ja auch ein eingeschränkter Account der beispielsweise nur config Dateien ändern kann und die üblichen benötigten Sachen um neue Programme zu installieren wie wget tar und gcc...allerdings weiss ich auch da nicht wie ich das _SICHER_ realisiere...

Lese mich gerade über chroot schlau ist das in meinem Fall sinnvoll?

AIDE werde ich mir aber auf jedenfall auhc mal ansehen..

Für neue Lösungswege bin ich nach wie vor offen ;)

[flo]

Und naja vielleicht reicht ja auch ein eingeschränkter Account der beispielsweise nur config Dateien ändern kann und die üblichen benötigten Sachen um neue Programme zu installieren wie wget tar und gcc...allerdings weiss ich auch da nicht wie ich das _SICHER_ realisiere...

eben - siehe oben. Solche Sachen muß man nicht unter dem root-Account erledigen.

[Roger Wilco]

für jedes Problem gibt es eine Lösung ich könnte mir doch zb die ausgabe von .bash_history automatisch auf einen entfernten Server senden auf dem der Freund dann keinen Zugriff hat...

"unset HISTFILE" am Anfang der Session und du hast keine Logs. Tolle Idee.
In so einem Fall wäre eher grSecurity mit den ganzen zusätzlichen Logging Mechanismen (Exec Logging usw.) zu gebrauchen.

Die Patentlösung für dein Problem lautet aber: Gib ihm keine Rechte. Frag ihn einfach jedesmal oder lerne es selbst...

Lese mich gerade über chroot schlau ist das in meinem Fall sinnvoll?

Nein.

[flo]

In so einem Fall wäre eher grSecurity mit den ganzen zusätzlichen Logging Mechanismen (Exec Logging usw.) zu gebrauchen.

was dann gegebenenfalls noch auf der gleichen Maschine liefe, bei einer falschen Config zur Runtime abschaltbar wäre. Viel zu viel Schwachstellen.

Da sehe ich eher praktische Probleme - wer soll sich hinterher das Logfile ansehen? System neu aufsetzen dauert weniger lange, als das durchforsten von xMB-Textdatei nach einem unbekannten Muster.

Die Patentlösung für dein Problem lautet aber: Gib ihm keine Rechte. Frag ihn einfach jedesmal oder lerne es selbst....

ACK

[Anonymous]

Wie wäre es mit sudo?