Ich habe festgestellt, dass ich unter Linux mit dem Aufruf von rt_sigqueue syscall in den Feldern si_uid und si_pid beliebig setzen kann und der Aufruf erfolgreich ist und die falschen Werte liefert. Natürlich bieten die uid-Beschränkungen beim Senden von Signalen einen gewissen Schutz gegen diese Art von Spoofing, aber ich bin besorgt, dass es gefährlich sein könnte, sich auf diese Informationen zu verlassen. Gibt es eine gute Dokumentation zu dem Thema, das ich lesen könnte? Warum erlaubt Linux das offensichtlich falsche Verhalten, den Aufrufer die siginfo -Parameter angeben zu lassen, statt sie im Kernelspace zu generieren? Es scheint unsinnig, vor allem seit extra sys
Calls (und damit Performance-Kosten) können erforderlich sein, um die UID / GID im Userspace zu erhalten.
Bearbeiten: Basierend auf meiner Lektüre von POSIX (Betonung hinzugefügt von mir):
Wenn si_code SI_USER oder SI_QUEUE, [XSI] oder ein Wert kleiner oder gleich 0 ist, wurde das Signal von einem Prozess erzeugt und si_pid und si_uid sollten auf die Prozess-ID und die reale Benutzer-ID gesetzt werden des Senders.
Ich glaube, dieses Verhalten von Linux ist nicht konform und ein ernsthafter Fehler.
Der Abschnitt der POSIX-Seite, den Sie angeben, listet auch auf, was si-code bedeutet, und hier ist die Bedeutung:
In diesem Abschnitt heißt es weiter:
Wenn das Signal nicht von einem erzeugt wurde der aufgelisteten Funktionen oder Ereignisse oben,
si_codewird entweder gesetzt zu einem der signalspezifischen Werte beschrieben in XBD, oder zu einem implementierungsdefinierter Wert ist ungleich keinem der definierten Werte oben.
Nichts wird verletzt, wenn nur die Funktion sigqueue() SI_QUEUE verwendet. Ihr Szenario enthält anderen Code als die Funktion sigqueue() mit SI_QUEUE Die Frage ist, ob POSIX ein Betriebssystem vorschreibt, das nur eine bestimmte Bibliotheksfunktion (im Gegensatz zu einer Funktion, die keine POSIX-definierte Bibliotheksfunktion ist) erzwingen darf Machen Sie einen Systemaufruf mit bestimmten Merkmalen. Ich glaube, die Antwort ist "Nein".
BEARBEITEN ab dem 2011-03-26, 14:00 PST:
Diese Änderung ist eine Reaktion auf den Kommentar von R .. von vor acht Stunden, da die Seite mich keinen ausreichend umfangreichen Kommentar hinterlassen ließ:
Ich denke, Sie haben grundsätzlich Recht. Aber entweder ist ein System POSIX-konform oder nicht. Wenn eine Nicht-Bibliotheksfunktion einen Syscall ausführt, der zu einer nicht kompatiblen Kombination aus UID, PID und 'SI_Code' führt, macht die zweite Anweisung, die ich zitiert habe, klar, dass der Aufruf selbst nicht konform ist. Man kann dies auf zwei Arten interpretieren. Eine Möglichkeit ist: "Wenn ein Benutzer diese Regel verletzt, macht er das System nicht konform." Aber du hast Recht, ich denke, das ist albern. Was nützt ein System, wenn nichtprivilegierte Benutzer es nicht kompatibel machen können? Der Fix, wie ich es sehe, ist es, das System irgendwie wissen zu lassen, dass es nicht die 'sigqueue ()' der Bibliothek ist, die das System aufruft, dann sollte der Kernel selbst 'si_code' auf etwas anderes als 'SI_QUEUE' setzen und die Uid und Pid, wie Sie sie setzen. Meiner Meinung nach sollten Sie dies mit den Kernel-Leuten besprechen. Sie können jedoch Schwierigkeiten haben; Ich kenne keinen sicheren Weg, um festzustellen, ob ein Syscall von einer bestimmten Bibliotheksfunktion ausgeführt wird, und wie die Bibliothek funktioniert. fast per Definition, sind nur Convenience-Wrapper um die syscalls. Und das mag ihre Position sein, von der ich weiß, dass sie eine Enttäuschung sein wird.
(voluminös) EDIT vom 2011-03-26, 18:00 PST:
Wieder wegen der Beschränkungen der Kommentarlänge.
Dies ist eine Antwort auf den Kommentar von R .. vor etwa einer Stunde.
Ich bin ein wenig neu für das Syscall-Thema, also bitte bitte mit mir.
Mit "the kernel sysqueue syscall" meinen Sie den Aufruf "__NR_rt_sigqueueinfo"? Das ist der einzige, den ich gefunden habe, als ich das getan habe:
Wenn das der Fall ist, denke ich, dass ich Ihren ursprünglichen Standpunkt nicht verstehe. Der Kernel lässt mich (nicht root) SI-QUEUE mit einer gefälschten PID und UID ohne Fehler benutzen. Wenn ich die sendende Seite so codiert habe:
und die Empfangsseite so codiert:
%Vor%Ich kann dann auf der Empfangsseite also (nicht root) laufen:
%Vor%Und sehen Sie dies (nicht-root) auf der Send-Ende:
%Vor% Wie Sie sehen können, hat das dritte Event pid und uid getäuscht. Ist das nicht das, was Sie ursprünglich abgelehnt haben? Es ist kein EINVAL oder EPERM in Sicht. Ich denke, ich bin verwirrt.
Ich stimme zu, dass si_uid und si_pid vertrauenswürdig sein sollten, und wenn sie es nicht sind, ist es ein Fehler. Dies ist jedoch nur erforderlich, wenn das Signal SIGCHLD durch eine Statusänderung eines untergeordneten Prozesses generiert wird oder wenn si_code SI_USER oder SI_QUEUE ist oder wenn das System die XSI-Option und si_code <= 0 unterstützt. Linux / glibc übergibt auch si_uid und si_pid -Werte in anderen Fällen; Diese sind oft nicht vertrauenswürdig, aber das ist kein POSIX-konformes Problem.
Natürlich darf das Signal für kill() nicht in die Warteschlange gestellt werden. In diesem Fall liefert siginfo_t keine zusätzlichen Informationen.
Der Grund, dass rt_sigqueueinfo mehr als nur SI_QUEUE zulässt, ist wahrscheinlich die Implementierung von POSIX asynchroner I / O, Message Queues und pro-process-Timer mit minimaler Kernel-Unterstützung. Die Implementierung in das Benutzerland erfordert die Fähigkeit, ein Signal mit SI_ASYNCIO , SI_MESGQ und SI_TIMER zu senden. Ich weiß nicht, wie glibc die Ressourcen zuweist, um das Signal vorher in die Warteschlange zu stellen; für mich sieht es nicht so aus und hofft einfach rt_sigqueueinfo scheitert nicht. POSIX verbietet eindeutig das Verwerfen eines Timerablaufs (asynchrone E / A-Beendigung, Nachrichtenankunft in einer Nachrichtenwarteschlange), da zu viele Signale zum Zeitpunkt des Ablaufs in die Warteschlange eingereiht werden; Die Implementierung hätte die Erstellung oder Registrierung ablehnen müssen, wenn die Ressourcen nicht ausreichen. Die Objekte wurden sorgfältig definiert, so dass jede E / A-Anforderung, jede Nachrichtenwarteschlange oder jeder Zeitgeber höchstens ein Signal im Flug haben kann.