Frage zum Abtrennen der (E-)Mail vom normalen Nutzer

[serie300]

Hallo

ich finde es nicht so toll, daß das Mail Verzeichnis in meinem normalen Benutzeraccount offen einsehbar ist (benutze sylpheed); es sitzt vielleicht jemand anderes mal an meinem Rechner oder ein Programm oder eine Webanwendung (ich weiß das sollte eigentlich abgeschottet sein) schaut "zu meiner Sicherheit" mal dort nach. Den Ansatz Mails nicht in dubiosen Datenbanken zu speichern, sondern im Verzeichnis Baum finde ich schon sinnvoll. Jetzt habe ich mir überlegt, ich mache einen extra User bei dem die Mail und sylpheed läuft und zum Starten starte ich einen Batch, der nach dem Passwort fragt, via su den Benuter wechstelt und dann sylpheed startet. Nach dem Schließen von sylpheed beendet der Batch und logt den Mail Benutzer aus.

Fragen:
1. Ist das sinnvoll oder gibt es eine bessere Methode?
2. Ich habe jetzt nach vielen Jahren mal wieder das Starten einer X Anwendung (und sylpheed wäre eine) aus einem über 'su' aufgerufenen Account probiert. X sperrt das. Mit 'export DISPLAY=:0' und 'xhost' bin ich nicht weiter gekommen - Meldung "Unable to init server: Verbindung mit 127.0.0.1 ist gescheitert: Connection refuse". Was muß ich da noch machen?

Serie300

 

[Zoi]

ich finde es nicht so toll, daß das Mail Verzeichnis in meinem normalen Benutzeraccount offen einsehbar ist (benutze sylpheed); es sitzt vielleicht jemand anderes mal an meinem Rechner

Multiuser Betriebsystem? Home absperren?

Ich habe jetzt nach vielen Jahren mal wieder das Starten einer X Anwendung (und sylpheed wäre eine) aus einem über 'su' aufgerufenen Account probiert. X sperrt das.

Lösung dafür kenne ich aus dem ff gerade nicht, aber ich würde dafür einfach passwordless ssh benutzen, mit Austausch des public key und dann das Programm mit ssh -X <cmd> aus dem batch heraus starten

 

[Andy_m4]

ich finde es nicht so toll, daß das Mail Verzeichnis in meinem normalen Benutzeraccount offen einsehbar ist

Das ist der Ansatz den das Benutzerkonzept verfolgt. Jedem Prozess ist ja ein UNIX-Benutzer zugeordnet und der darf dann auf alle Dateien zugreifen, auf der der korrespondierende Nutzer auch zugreifen darf.
Manchmal ist das nicht feingliedrig genug.

Ist das sinnvoll oder gibt es eine bessere Methode?

Kann man im Prinzip so machen.
Eine Alternative wäre eine Jail. Allerdings gewinnst Du nicht viel gegenüber nem getrennten Account.

Ich habe jetzt nach vielen Jahren mal wieder das Starten einer X Anwendung (und sylpheed wäre eine) aus einem über 'su' aufgerufenen Account probiert. X sperrt das. Mit 'export DISPLAY=:0' und 'xhost' bin ich nicht weiter gekommen - Meldung "Unable to init server: Verbindung mit 127.0.0.1 ist gescheitert: Connection refuse". Was muß ich da noch machen?

Du kannst ssh benutzen um Dich mit einem anderen Nutzer-Account anzumelden:
ssh -Y mailaccount@localhost

Das -Y sorgt dafür, das Du X11-Anwendungen starten kannst.
Wenn man will, kann man das auch auch mit dem pubkey-Verfahren machen. Dann brauchst Du nicht mal mehr ein Passwort eintippen und kannst so komfortabel Programme unter anderer Nutzerkennung ausführen.

siehe auch die Mapage von ssh:
https://www.freebsd.org/cgi/man.cgi?query=ssh&apropos=0&sektion=1

Zur pubkey-Geschichte steht auch was im Handbuch:
https://docs.freebsd.org/de/books/handbook/security/#openssh

 

[CommanderZed]

Was schützt dich denn davor, das jemand ein boswilliges script oder eine böswillige library in deinem Homeverzeichniss und .kshrc (o.ä.) setzt das z.B. deine Passworteingabe mitschneidet oder noch schlimmeres macht sobald er irgendwie Code mit deinen oder Root-Rechten ausführt?

Wenn du deinem System inkl. der integrität deines Benutzers nicht trauen kannst, bist du, auf gut deutsch gesagt, gearscht.

Hier helfen die vielen gängigen absicherungen wie z.B. gute Kennwörter, FDE, automatischer lock des Bildschirms, aktuelle Sicherheitspatches, sinnvolle strukturierung des Systems und die ganzen üblichen "best practices". Das wäre so grob auch mein Fokus.

Alternativ wenn dir das wirklich auf der Seele brennt eine alternative Lösung:
Du speicherst die Sylpheed-Daten in einen verschlüsselten Container.
Um den Vorgang herum bastelst du dir ein kleines Script das nach dem Passwort fragt und erst dann Sylpheed startet. Wenn du Sylpheed schließt, lässt du den Container automatisch unmounten. Dadurch ist der Zugriff auf die Daten nur mit dem Passwort und nur für die Zeit des Zugriffs möglich.
Sowas in die Richtung hab ich unter OpenBSD und unter Linux mit luks vor längerem mal aus ganz anderen gründen gebastelt und lief recht unaufällig.

 

[serie300]

OK
Andy_m4 hat mir geholfen. Ich wollt jetz keine Sicherheitsdiskussion und keine Diskussion über Hacking und UNIX Filesysteme anstoßen, ich wollte nur mit einfachen Mitteln mein Mail Verzeichnis "hinter einen Zaun setzen", wenn ich mit meinem Standard Account arbeite
Serie300

 

[Andy_m4]

wollte nur mit einfachen Mitteln mein Mail Verzeichnis "hinter einen Zaun setzen", wenn ich mit meinem Standard Account arbeite

Wobei der Einwand vom "Commander" nicht ganz von der Hand zu weisen ist. :-)
Am effektivsten ist der oben genannte "Trick" mit dem Prozess in Account einsperren wenn man es umgekehrt macht. Also wenn man ein Programm hat, dem man vielleicht nicht so zu 100% vertrauen möchte.

Aber wenn jetzt alles so ist, wie Du es haben möchtest, ist ja alles in Ordnung.

Was man evtl. noch gucken müsste ist, das man das Home-Verzeichnis vom jeweilig anderen Nutzer nicht betreten kann. Bei Systemen wie FreeBSD ist das standardmäßig nicht der Fall.

 

[CommanderZed]

Villeicht noch ganz interessant, OpenBSD hat dafür die pledge und unveil funktion wenns z.B. ums Webbrowsen geht

Diese beschränkt den Firefox & Chromium auf den Download-Ordner & das Profil e.t.c. k.a. obs sowas in die Richtung auch unter FreeBSD gibt (Du verwendest FreeBSD?)

Villeicht ja als nette weitere Sicherheitsfunktion für dich ganz interressant.

 

[midnight]

Man koennte dem Mailclient auch sagen, bis auf die Betreffs keine Inhalte offline zu cachen. Das IMAP-Passwort wird auch nicht im Schluesselbund gespeichert und muss bei jeder Session neu eingegeben werden.

Alle diese und oben genannten Massnahmen nuetzen aber nichts, wenn das System entsperrt ist und man seinen Arbeitplatz verlaesst, ohne das System wieder zu sperren. Wenn das System allerdings gesperrt ist, benoetigt man normalerweise auch diese Massnahmen nicht. Es sei denn, man teilt den Useraccount mit anderen Personen.

 

[Andy_m4]

k.a. obs sowas in die Richtung auch unter FreeBSD gibt

Etwas was bei FreeBSD in eine ähnliche Richtung geht ist Capsicum.

Das sind aber eher Frameworks um Programmierern zu helfen, in ihren Programmen Privilege-separation / Sandboxing zu machen. Wobei es auch Tools gibt, um das sozusagen Anwender zugänglich zu machen um es auf beliebige Programme anzuwenden.
Im Falle von Capsicum wäre das der Capsicumizer (so ein bisschen das was firejail unter Linux mit Hilfe von Namespaces und Seccomp macht).

Aber auch hier wieder:
Das ist eher ein Tool um ein potentiell problematisches Programm einzusperren, als es vor dem Rest des Systems zu beschützen.