Fragen? Antworten! Siehe auch: Alternativlos
Ein Ansatz dazu wäre, dass man dem Prozess per LD_PRELOAD eine Shared Library reindrückt, die dann open() überschreibt mit einer Version, die über einen vorher etablierten Unix Domain Socket einen Broker-Prozess bittet, für ihn die Datei zu öffnen. Der Broker prüft dann den Dateinamen und die gewünschten Zugriffsrechte (beispielsweise anhand einer Konfigurationsdatei), und wenn das OK ist, dann macht er die Datei auf und schiebt den Deskriptor über den Unix Domain Socket zurück. Daher auch ein Unix Domain Socket als Kommunikationsweg, denn da kann man Deskriptoren rüberschieben.
Das offensichtliche Problem mit diesem Ansatz war immer, dass man mit LD_PRELOAD zwar verhindern kann, dass jemand versehentlich open() aufruft, aber nicht dass jemand von Hand den Syscall absetzt. Da gab es dann bisher so Ideen von wegen "der Broker hängt sich mit ptrace an den Prozess und killt ihn, wenn er open() aufruft". Das geht, aber ptrace … nunja. Gut, nicht dass Seccomp so viel weniger übel ist als API, aber mit Seccomp kann man in einem Initialisierer in der Shared Library (jetzt kommt die Einsicht) auch einen Seccomp-Filter einrichten, der den open-Syscall verbietet. Der sollte dann natürlich auch andere Dinge verbieten (ich persönlich bin an der Stelle immer ein Freund von whitelisting statt blacklisting).
Aber mein Punkt ist: Man kann jetzt mit LD_PRELOAD dank Seccomp tatsächlich einen fremden Prozess dazu bringen, dass er (sogar halbwegs transparent) keine bösen Dateisystemzugriffe macht.
Gut, der Teufel liegt natürlich wie immer im Detail. Dann muss man auch schauen, dass man chdir und fchdir und so folgt, und wenn man Lesezugriffe auch verhindern will, dann muss man auch stat und co abfangen.
Aber hey, wenn es einfach wäre, wäre es nicht interessant :-)
Man kann das jetzt machen. Ich habe mal einen kleinen Proof of Concept gehackt, die das für open() tut. Mal gucken, ob ich den in einen verwendbaren Zustand kriege und dann veröffentlichen kann.