Abfragen von Systeminformationen

[BinEinGast]

warum? alles was eine os-funktion kann, kann ein dienstprogramm auch

Eher andersrum ^^ alles was ein dienstprogramm kann sollt eine Api vom BS auch oder ^^ wobei man hier sehr wohl unterscheiden muss, auf welchen Standard man sich runner begibt (Posix, Distri )

so kann man das auch sehen. mir war zu diesem zeitpunkt nur nicht klar, warum die verwendung von dienstprogrammen schon durch die aufgabenstellung ausgeschlossen sein soll, da es nicht daran liegen kann, daß sie nicht mächtig genug sind. jetzt ist klar, daß du es wegen 'eklatanten sicherheitsproblemen' ausschließt, wobei mir noch immer nicht klar ist, warum die verwendung von programmaufrufen/os-funktionen sicherheitskritisch sein soll.

mal ein szenario für begriffsstutzige (wie u.a. mich): ich schreibe ein programm, das zu einem server eine verbindung aufbaut, sich vom eigenen os-kern die MAC eines beliebigen net-controllers geben läßt und eine APDU mit der MAC als inhalt an den server sendet.

ist deiner meinung nach der syscall zum erhalten der MAC kritisch oder ist es kritisch, daß die funktion zum abfragen überhaupt zur verfügung steht, weil z.b. viren, etc. damit unfug treiben könnten?

das betriebssystem stellt auch nur solche funktionien zur verfügung, die der 'nutzer' auch nutzen können soll.

und du willst programme schreiben die drueber hinausgehen ? dann solltest aber auch damit leben, dass dein programm nicht mehr portabel und plattformunabhaengig bleibt ....

es ging rein um den von dir angesprochenen sicherheitsaspekt

exec/system aufruf als solches immer mit sich bringt, egal was man da genau aufruft

nach genau denen frage ich dich ja

Wenn man die sache einmal macht ... ok
wenn man die infos aber 20 mal die sekunde braucht ....
und ich red ned um overhaed den das hilfsprogramm brauch, sondern overhead den dein programm braucht um den eigenen prozess fuers hilfsprogramm zu ueberlagern ...
zum besipiel ruf mal zigtausend mal gethostbyname auf, oder parse zigtausend mal den ausgabestream von nem exec ("nslookup irgendwas").

man kann sich natürlich immer eine situation konstruieren, in der eine bestimmte lösungsmöglichkeit ausscheidet. in der von dir oben beschriebenen gebe ich dir recht.

ich vertrete auch nicht die meinung, daß, wann immer man vor der entscheidung steht die ausgabe eines dienstprogrammes zu parsen oder eine os-funktion aufrufen, die erste methode die einzig wahre ist, sondern daß es vielmehr eine design-entscheidung ist, wie du selbst gesagt hast:

Ich behaupte nicht das scripts keine vorteile haben ... wenn ein script meine anforderungen erfuellt, ist es meist sogar die bessere variante, weil es eben weniger entwicklungszeit verbraucht hat, aber darum gehts hier wohl nicht oder ?

Das Osi Schichtmodell haett mir mein Informatiklehrer bei der Frage um die Ohren gehauen ^^

...

Im ernst, wenn du TCP/IP im speziellen falle UDP verwenden willst, solltest du dich an konventionen halten.

TCP/IP : UDP/IP war nur als beispielszenario gedacht

Im ernst, wenn du TCP/IP im speziellen falle UDP verwenden willst, solltest du dich an konventionen halten [...] nicht mal auf TCP/IP schicht [...]

zieh mal den kopf ein, sonst gibt's ärger vom pauker.

erklär mir doch bitte erst mal, was du unter TCP/IP-schicht verstehst. TCP ist, soweit ich weiß, transportschicht (schicht 4), IP netzwerkschicht (schicht 3). zugegeben, schichten 3 und 4 verschmelzen stark, aber dann kann ich durchaus eigene, auf schicht 2 (MAC-verwendende protokolle) neue protokolle aufsetzen, die die schicht 3/4 ausfüllen.

Und eine davon ist, das die MAC eben Implementationsdetail ist [...] TCP/IP frames verwenden und gleichzeitig MAC adressen auswerten

gleichzeit mit MACs und IP-packets zu arbeiten ist natürlich indiskutabel. wenn du aber selbst die schichten 3/4 implementieren willst, ist die MAC für dich selbst kein implementierungsdetail mehr.

schreibst du programme oder Tools zur systemverwaltung ^^ das ist nen unterschied, und zwar nen gewaltiger ^^

ich rede die ganze zeit nur von programmen, die im user-space operieren. ob die system-inis editieren oder über's netzwerk irgendwelche server konfigurieren, ist da doch (falls ich mich irre laut stop schreien) egal.
ich habe außerdem nicht unterschieden, ob das programm von root oder dem rest der welt aufgerufen werden kann.

ich glaube die ganze diskussion hängt daran, daß wir zu allgemein argumentieren. ein diskussion darüber, wann man scriptet statt zu coden, wann man os-funktionen, interrupt-routinen oder dienstprogramme verwendet und lauter so zeugs fände ich hingegen sinnvoll.

Konstant schon, aber das Starten des externen Executables ist Overhead und das Parsen des Outputs auch.

es stellt sich ja auch die frage, ob es nicht situationen gibt, in denen dieser overhead nicht trotzdem sinnvoll ist, oder nicht ins gewicht fällt, weil bla bla ...

Abgesehen davon ist das Parsen eines Programmoutputs, der nicht für maschinelle Weiterverarbeitung gedacht ist, also keinen definierten Konventionen folgt, immer eine problematische Sache. Thematik Screenscraping.

jup

[RHBaum]

ich glaube die ganze diskussion hängt daran, daß wir zu allgemein argumentieren. ein diskussion darüber, wann man scriptet statt zu coden, wann man os-funktionen, interrupt-routinen oder dienstprogramme verwendet und lauter so zeugs fände ich hingegen sinnvoll.

Richtig ^^

Der Threadersteller hatte gefragt, z.b. wie er mit C/C++ auf die Mac adresse einer eingebauten Netzwerkkarte kommt. Und noch andere informationen.

Und sich "beschwert" das eben diese Informationen nicht einheitlich zur verfuegung stehen ....

Und genau hier kolliediert er mit der Philosophie des Betriebssystemes. Ein Unix stellt dir eine Schnittselle / eine definierten umfang von Hilfsprogrammen / BS-API's zur verfuegung. Diese Standards (Posix SystemV) werden aber von unterschiedlichen Unixen (Linux, Linux distries) unterschiedlich erreicht ...
Also ist eine Mac Adresse z.b. ein Implementationsdetail ... in dem falle vom TCP/IP Stack. Einem Unix / Linux etc ist nicht vorgeschrieben, wie es die MAC adressen seiner karten zu verwalten hat, sondern nur die TCP/IP funktionen muessen gehen ^^ Und genau das ist das eigentliche philosophische Problem an der Sache ^^

wenn du aber selbst die schichten 3/4 implementieren willst, ist die MAC für dich selbst kein implementierungsdetail mehr.

Natuerlich nicht mehr ... aber das ist dann auch kein UNIX kompatibles problem mehr ^^ Du baust nen eigenes Protokoll an der Stelle, und das ist nicht mehr teil des Standards ... du greifst auf tiefere ebenen zu, die nicht mehr standardisiert sind.
Und deshalb meine Aussage, du kannst dann von Unix (Posix, SystemV) nicht mehr erwarten, die Informationen und functionalen einsprungpunkte zu einfach bekommen, die du zur implementation brauchst ... Im gegenteil, du musst damit rechnen dass deine Loesung nicht mehr unter jedem Unix / Linux laeuft, und du wahrscheinlich fuer jede Version wo es drauf laufen soll, vielleicht auch bei der selben distrie nur unterschiedliche versionsnummern, anpassungen vornehmen musst ....

Viele tools fuer die administration (dhcp, iptables, ipfwadm etc) greifen natuerlich weiter unten zu, sind aber auch kein bestandteil der standards ... es gibt durchaus z.b. noch unixe wo kein iptables laeuft ... und fuer den dhcpd und dhcp_client gibt es mehrere implementationen, die sich teilweise unnerschiedlich verhalten

Natuerlich ist dhcp (als protokoll) z.B. standardisiert, aber es ist kein bestandteil von SystemV oder Posix, und auch ned von TCP/IP

TCP ist, soweit ich weiß, transportschicht (schicht 4), IP netzwerkschicht (schicht 3).

Ich hoffe mein Lehrer sieht das nicht ^^ aber ich glaub der Standard TCP/IP -Stack deckt Schicht 3-5 sogar ab.

Ging darum das TCP/IP nix mit schicht 2 zu tun hat ...

warum die verwendung von dienstprogrammen schon durch die aufgabenstellung ausgeschlossen sein soll

Das es nicht alle programme gibt, schliess ich mal aus ... fuer alle hilfsprogramme die im standard sind, gibt es meist auch ne entsprechende API funktion / oder andersrum ...

Aber an nen richtiges binary hat man meist komplett andere Anforderungen wie an nem script.

Geschwindigkeit ist manchmal ein faktor, wird aber meist viel zu hoch bewertet .... scripte sind in den meisten faellen schnell genug

Sicherheit ist ein thema ... nen script hat immer sicherheitsluecken. bei einem Script kann und werde ich auch nur erwarten, das es maximal so sicher ist wie die verwendeten hilfstools. wenn mir wer da nen trojaner unnergeschoben hat, bin ich mitm script machtlos ...
bei nem binary erwart ich das nicht aufm ersten blick ^^
das mir einer meine systemlibs verbiegt, ist viel unwahrscheinlicher, wenn auch nicht ausgeschlossen. Aber bei so nem komprimittierten system ist gar nix mehr sicher ....

wenn ich externe tools in nem binary verwende kommt meist frueher oder spaeter der wunsch auf, das konfigurierbar zu machen ... beispielsweisse ob ich grep oder egrep irgendwo verwende ... diese einstellung und die Ablage der Info muesst ich auch absichern ... sonst schiebt mir da wer sonstwas unter ....

suchpfade, userid ... mit welchen rechten laeuft das tool, wie stehen die umgebungsvariablen, das hat auswirkungen auf den start des tools .... bei nem script acht ich als admin expliziet drauf, bei nem binary erwart ich einfach nicht das ich darauf achten muss ....

und last but not least ... verhalten bei out of memory / buffer-stack overflow / system haengt.
Bei nem C programm kann ich zumindest darauf achten, das in solchen faellen nichts sicherheitskritisches passiert .... bei nem exec aufruf verlier ich da total die kontrolle, da kann ich kaum mehr was garantieren .... Wenn in dem falle mein exec zurueckkehrt und die speicherbereiche zurueckgeschrieben werden ist undefiniert was da drinne steht, das kann sich nen angreifer zunutze machen ....

Bei nem Script ist die gefahr allgegenwaertig, nen script muss ich halt von aussen absichern ....
nen binary sollt auch in ner unsicheren umgebung sicher sein ....
Scripts laufen auch meist nicht wirklich lange .... su tun was, gut ist ^^
nen programm laeuft teilweisse ueber stunden ... wenn es ne oberflaeche hat, macht der User was damit ....
In der Zeit kann sich der systemzustand aendern, da sollt das binary immer noch sicher sein und damit klarkommen, bei nem script erwart ich das nich unbedingt ...

Ciao ...