[linux-l] Re: /proc & Co.

[olafBuddenhagen at gmx.net]

Hallo,

On Sun, Oct 22, 2006 at 09:47:40PM +1000, Peter Ross wrote:
> On Sat, 21 Oct 2006, olafBuddenhagen at gmx.net wrote:

> > Bei Dateisystem-Aufrufen ist der Eintrittspunkt genauso exakt
> > definiert, nur dass er sich an einer anderen Stelle befindet. (Nicht
> > im Code der den Syscall selbst entgegennimmt, sondern erst in dem
> > Code der sich um eigentliche pseudo-Datei kümmert.)
> 
> Es gibt ja noch mehr als nur das herkoemmliche
> User-Group-Others-Zugriffsrechtekonzept, SELinux z.B., oder FreeBSDs
> jail, und dann wird es richtig haarig, wenn man etwas zunaechst
> "offenes" wie ein Filesystem nachtraeglich abdichtet. Das
> Windows-Syndrom..

Richtig, das nachträgliche abdichten ist immer haarig -- das gilt für
SELinux und Jails und den ganzen anderen Kram ganz generell. UNIX ist
halt vom Prinzip her kein System was heutigen Sicherheitsanforderungen
wirklich gerecht wird; und das kann man num mal nicht ändern, ohne
ziemlich grundlegende Änderungen an einigen Konzepten vorzunehmen.

> jail, auch wenn es nicht Linux, sondern FreeBSD ist, ist ein
> exzellentes Beispiel, weshalb ich es eroertern will. Jeder Prozess hat
> eine Jail-ID, die abgefragt wird, wenn es um Zugriffe geht. Auch ist
> die Wurzel im Dateisystem fuer jedes Jail bekannt.
> 
> sysctl ist ein Eintrittspunkt fuer _alle_ Zugriffe auf das, was Du nun
> unter /proc hast. Hier kannst Du erstmal sagen, "wenn Prozess im Jail,
> dann Zugriff verweigert", und schon hast Du erst einmal ein sehr
> sicheres System, mit nur einer Zeile Programmcode im Kernel.. und
> davon ausgehend, kannst Du nach hinreichender Ueberlegung vielleicht
> das Tuerchen hier und da ein Stueckchen oeffnen. 

Sehe nicht wieso das bei Dateisystem-basierten Schnittstellen anders
sein sollte. Die Zeile steht nur eben wo anders.

> Ich sehe keinen echten Vorteil fuer den ganzen procfs-Kram unter mehr
> oder minder traditionellem Unix, nur, dass es einem ueberall auf die
> Fuesse fallen kann.

Darauf bin ich in einem etwas anderen Zusammenhang in meinem letzten
Vortrag ziemlich breit eingegangen. (Der dummer Weise hier nicht
angekündigt wurde...)

Zum einen sind solche Schnittstellen generell meist ziemlich intuitiv
und leicht erlernbar. Sie bauen halt auf Dateisystem-Konzepten auf, die
jedem UNIX-Nutzer hinlänglich vertraut sind. Man muss nur noch wissen,
wie die Daten in der Hierarchie abgelgt sind; man muss sich nicht um
Spezifika von Funktionsaufrufen kümmern.

Da nur normale UNIX-Mechanismen verwendet werden, kann man die gleiche
Schnittstelle direkt von der Kommandozeile mit den gewöhnlichen
Datei-Werkzeugen nutzen, aber auch in Shell-Skripten, C-Programmen,
Perl-Skripten, was auch immer. Somit kann man oft bereits Vorhandenes
Wissen von der "manuellen" Anwendung direkt nutzen, wenn man ein
Programm schreibt. Auch sind keinerlei Sprachspezifische Bindings nötig.
Man kann neue Schnittstellen sofort nutzen, in jeder Sprache.

> > Wie geht Plan9 damit um?
> 
> Gute Frage.. Ich habe eine leise Ahnung, aber kein Detailwissen ueber
> Plan9, aber soweit ich weiss, sind Files dort ein so grundlegendes
> Konzept, dass eher das VFS darauf aufbaut, um eine
> "Unix-Schnittstelle" zu etablieren. Es ist eben kein traditionelles
> Unix. Moeglicherweise gibt es daher dort besser Moeglichkeiten, damit
> umzugehen, aber dann eher "ganz unten" im System.

Keine Ahnung wovon Du redest. Naja, sollte mich wohl wirklich mal etwas
intensiver mit Plan9 befassen...

-Olaf-