• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Programm als anderer Benutzer, Drag & Drop funktioniert nicht

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Noch krasser: Du kannst nicht auf Adressräume zugreifen die einem andern Prozess gehören.

Dann zaubern wir mal ein bißchen:

Ein Programm "write" schreibt in den Speicher des anderen Programmes "wait", genauer gesagt in die Variable "myInt", die den Wert 0 hat, des anderen Programmes "wait". Sobald diese Variable den Wert 1 ("true" in der if-Abfrage) hat, beendet sich "wait". Programm "wait" ändert den Wert nicht selbst, sondern hängt ansonsten in einer Endlosschleife (while (true aka 1)) fest.

Das Programm "write" holt sich vollen Zugriff auf "wait" mit Hilfe von task_for_pid() und schreibt an die Speicherstelle in dem Adreßraum von "wait", an dem "myInt" liegt. Die PID von "wait" ist Input für "write".

Der Mach-Port, der zur Task mit gegebener Prozeß-ID gehört, gibt dem aufrufenden Prozeß volle Kontrolle über den anderen.

KeyWest:taskforpid macmark$ cat wait.c
Code:
#include <stdio.h> 

static int myInt = 0;

int main(int argc, char* argv[])
{
	fprintf(stdout, "Waiting with int %d on address %p.\n", myInt, &myInt);
	while (1) {
		if (myInt) {
			fprintf(stdout, "Someone else changed the value of myInt.\n");
			return 1;		
		}
	}		
}


KeyWest:taskforpid macmark$ gcc -Wall wait.c -o wait -arch i386

Wir müssen die Adresse von myInt rausfinden:

KeyWest:taskforpid macmark$ nm wait | grep myInt
0000203c b _myInt

Nun verwenden wir Adresse 0x203c in "write":
KeyWest:taskforpid macmark$ cat write.c

Code:
#include <stdlib.h> 
#include <mach-o/dyld.h>
#include <mach/mach_traps.h>
#include <mach/mach_init.h>
#include <mach/message.h>
#include <mach/vm_map.h>
#include <mach/vm_region.h>
#include <stdio.h>  
#include <mach/mach_port.h>
#include <mach-o/fat.h>
#include <mach-o/nlist.h>

#define TARGETADDRESS 0x203c

int main(int argc, char* argv[])
{
	mach_port_name_t task;
	int pid = atoi(argv[1]);
	int error = task_for_pid((mach_port_name_t)task_self_trap(), pid,(mach_port_name_t *) &task);
	if (error) {
		fprintf(stderr, "Could not access task for pid %d.\n", pid);
		return error;
	} 
	else {
		fprintf(stdout, "Got the process %d's task Mach port : %x\n", pid, task);
	}

	long newValue = 1;	
	error = vm_write( task, (vm_address_t) TARGETADDRESS, (vm_address_t) &newValue, sizeof(newValue));
	if ( error ) {
		fprintf(stderr, "Error writing.\n");
		return error;
	} else {
		fprintf(stdout, "Successful written.\n");
	}
	
	return 0;
}


KeyWest:taskforpid macmark$ gcc -Wall write.c -o write -arch i386

KeyWest:taskforpid macmark$ ./wait &
[1] 725
KeyWest:taskforpid macmark$ Waiting with int 0 on address 0x203c.
sudo ./write 725
Password:
Got the process 725's task Mach port : 1107
Successful written.
KeyWest:taskforpid macmark$ Someone else changed the value of myInt.

[1]+ Exit 1 ./wait

Falls sich jemand um die Sicherheit sorgt: Die Funktion task_for_pid() prüft die UserIDs der betroffenen Prozesse und konsultiert, falls die UserIDs genehm waren, auch noch den taskgated-Dämon, der dann immer noch nein sagen kann.
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Würde es dann reichen einen "normalen" pbs als root laufen zu lassen
Um dem Programm eine bisher noch gar nicht vorhandene Funktion hinzuzufügen?
Tja, das wäre ein schöner Traum.

Ein von root gestarteter pbs wird dem Benutzer root dienen, so wie der von Benutzer A den Programmen von Benutzer A. Weiter nichts. (Auch wenn man sich als root nicht an der GUI anmelden kann, bzw es zumindest niemals tun soll.)

Kann es sein, dass lauchd etwas tut was er selber verbietet?
launchd verbietet das nicht, sondern die Funktionsweise von pbs.

Außerdem dauert das manchmal ganz schön lange bis "die Verbindung verloren geht". Müsste der launchd das nicht gleich merken?
pbs ist nicht nur das was du als "Zwischenablage" wahrnimmst, das ist nur eine seiner Aufgaben. Er kümmert sich um vielfältige Notwendigkeiten der Kommunikation zwischen Programmen. Neben Drag&Drop wird er beispielsweise auch bemüht, um essentielle Infos für Kontextmenüs, Dienste, verfügbare URIs oder andere übergreifende Funktionen auszutauschen. Welche dieser vielen Aktionen für das abschmieren im Detail verantwortlich ist, fragst du besser die Progger bei Apple.
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
]…]
KeyWest:taskforpid macmark$ Waiting with int 0 on address 0x203c.
sudo ./write 725
Password:
Got the process 725's task Mach port : 1107
Successful written.
*Möööööööööööööööööp*

Die Sache ist ganz einfach: Für die Trennung der Pasteboards nach Usern gibt es einen funktionalen Grund und genau gar keinen Sicherheitsaspekt.

+++

Nur am Rande: Auch bei seinem task_for_pid() nicht. Obwohl, doch schon, irgendwie, aber das hat wenig mit Mail.App und angemeldeten Nutzern zu tun. Mal schauen, ob er noch drauf kommt, warum er keinen Code liefern kann. (Außer mangelnder Fachkenntnis freilich)

Meinst du wirklich, Mail.App läuft mit Root-Rechten?

[ ] Ja
[ ] Nein
[ ] Aber klar doch!

Oder wolltest du beweisen, dass Programme mit Root-Rechten sicherheitstechnisch probematisch sind?

[ ] Ja
[ ] Nein
[ ] Aber klar doch!

Aber ich bin stolz, dass du noch drauf gekommen bist.
 

MacAlzenau

Golden Noble
Registriert
26.12.05
Beiträge
22.509
Ach ich liebe solche Threads.
Da werden endlich mal Messer gewetzt, das befriedigt die niederen Instinkte des Mitlesers. Da braucht man kein Privatfernsehen mehr, und eigentlich müsste es bei ApfelTalk auch die Quote in die Höhe treiben.
Wäre schön, wenn irgendwann, wenn die Cracks sich geeinigt haben, eine nette Zusammenfassung am Schluß stehen könnte, auf daß auch laienhafte, aber dennoch ernsthaft interessierte Nur-Nutzer wie ich etwas dazulernen.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
*Möööööööööööööööööp*…

Eigentlich hatte ich keinen Bock, Dir zu antworten, aber das Publikumsinteresse war zu groß. Und da habe ich zwischen Familie und Beruf halt mal ein paar Minuten abgezwackt.

So, nun zu Deinem Posting:

Mein Code war _ungewollte_, vom Zielprozeß ungeplante, Inter-Prozeß-Kommunikation (IPC). Es ginge auch ohne sudo, erfordert aber mehr Aufwand. Trusted signed code zum Beispiel. Bis Tiger konnten Peer-Prozesse auch ohne procmod-Group und ohne sudo auf Peers zugreifen.

So, nun zu Mail:
Das Pasteboard implementiert jedoch _gewollte_ IPC. Das benötigt kein sudo und kein task_for_pid(). Da schreibt man direkt in den genehmigten Bereich. Das heißt auch, daß Rastafari in diesem Thread (wie oft) vollkommen recht hat.

Nachtrag: Wird langsam Zeit, daß Du Deine Beleidigungen zurücknimmst. Sollte Dir schon aus Berufsehre wichtig sein … (Ich weiß, wer Du bist, obwohl Dein Profil hier unvollstandig zur Verfügung steht. …)
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Ja, das war mir klar.



Würde es dann reichen einen "normalen" pbs als root laufen zu lassen, oder müsste dazu der pbs anders beschaffen sein, als er es unter einem normalen Benutzer ist?



Aber dann dürfte der pbs doch nicht vom launchd unter User A neu gestartet werden, sonst sind es dann doch wieder zwei pbs unterhalb der selben launchd-Instanz. Kann es sein, dass lauchd etwas tut was er selber verbietet? Außerdem dauert das manchmal ganz schön lange bis "die Verbindung verloren geht". Müsste der launchd das nicht gleich merken?

Noch einmal: Das ist funktionale Absicht! Stell dir mal vor, mehrere Nutzer würden sich ein Pasteboard teilen. Es geht hier darum, dass es in Wahrheit ein Nutzer ist. Das kann das OS aber nun wirklich nicht ahnen.
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Eigentlich hatte ich keinen Bock, Dir zu antworten, aber das Publikumsinteresse war zu groß. Und da habe ich zwischen Familie und Beruf halt mal ein paar Minuten abgezwackt.

So, nun zu Deinem Posting:

Mein Code war _ungewollte_, vom Zielprozeß ungeplante, Inter-Prozeß-Kommunikation (IPC). Es ginge auch ohne sudo, erfordert aber mehr Aufwand. Trusted signed code zum Beispiel. Bis Tiger konnten Peer-Prozesse auch ohne procmod-Group und ohne sudo auf Peers zugreifen.

So, nun zu Mail:
Das Pasteboard implementiert jedoch _gewollte_ IPC. Das benötigt kein sudo und kein task_for_pid(). Da schreibt man direkt in den genehmigten Bereich. Das heißt auch, daß Rastafari in diesem Thread (wie oft) vollkommen recht hat.

Nachtrag: Wird langsam Zeit, daß Du Deine Beleidigungen zurücknimmst. Sollte Dir schon aus Berufsehre wichtig sein … (Ich weiß, wer Du bist, obwohl Dein Profil hier unvollstandig zur Verfügung steht. …)

Nein, es bedeutet, dass es kein Sicherheitsproblem gibt.

Du musst besondere Rechte haben, um in fremde Prozesse zu schreiben. Es hat immer noch nicht die geringste Bedeutung, wem dieser Prozess gehört. Zeig mir in deinem Code die Zeile, in dem es auf darauf ankommt, dass die beiden Prozesse einem bestimmten, nämlich demselben User gehören. Es gibt sie nicht. Ein systemweites Pasteboard würde das nicht einmal merken. Es müsste es explizit ausschließen, wenn es das mal nicht will.

Damit hatte Rastafarin ganz gewiss Unrecht, weil die Kommunikation zwischen zwei Prozessen des Users implementiert ist und zwischen zwei Prozessen verschiedener User nicht. Es gibt für den Code aber gar keinen Unterschied. Pasteboard macht das absichtlich so, weil ein gemeinsames Pasteboard funktiontal blödsinnig ist. Mit Sicherheit hat das gar nichts zu tun.

Übrigens ist kann nur root (et al.) den gemeinsamen Bereich genehmigen. Und damit dürfte klar sein, dass es ohnehin nicht auf Benutzer des Quell- und Zielprozesses ankommen kann.
 

salome

Golden Noble
Registriert
20.08.06
Beiträge
23.750
Bitte Amin Negm-Awad, warum wiederholst du dauernd in voller Länge, was ein anderer schreibt, statt schlicht zu antworten?
Der Thread ist lang genug udn in weiten Teilen ohnehin ein Dialog.
die Salome
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
… Du musst besondere Rechte haben, um in fremde Prozesse zu schreiben. Es hat immer noch nicht die geringste Bedeutung, wem dieser Prozess gehört. Zeig mir in deinem Code die Zeile, in dem es auf darauf ankommt, dass die beiden Prozesse einem bestimmten, nämlich demselben User gehören. Es gibt sie nicht. …

Du machst netterweise schonmal die Abgrenzung zu fremden Prozessen.

Vielleicht wirfst Du mal einen Blick in den Kernel-Code. Speziell den, der task_for_pid() implementiert. Da siehst Du ganz oft, daß nach User geprüft wird. Es hängt davon ab, wem die Prozesse gehören und nachgeordnet, ob man besondere Rechte benötigt. Diese Rechte haben sogar eigene Namen, die vom Security Framework gecheckt werden.

Bis Tiger konnte man nach Belieben mit task_for_pid() in seinen eigenen Prozessen rumpfuschen, aber keinenfalls in anderen. Inzwischen ist das _zusätzlich_ weiter eingeschränkt. Aber das ist wie gesagt nur _ungeplante_ IPC. Beim Pasteboard ist das jedoch anders. Ist Dir nicht klar, daß Prozesse zwischen Usern besser getrennt sind als innerhalb eines Users? Nicht? Dann teste mal mit "kill".
 
Zuletzt bearbeitet:

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Was er sagen möchte, ist, dass jeder User sein Pasteboard haben soll. Wenn du root als Pasteboard-Inhaber hast, dann hast du eben ein Pasteboard für root. Auch root ist ein User.

Was benötigt würde, wäre ein Pasteboard, dass jedem User als "sein Pasteboard" geliefert wird. Das ist aber eine Änderung des Konzeptes. Deshalb dürfte das frickelig werden, es mit den Bordmitteln zu erzielen.
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Bitte Amin Negm-Awad, warum wiederholst du dauernd in voller Länge, was ein anderer schreibt, statt schlicht zu antworten?
Der Thread ist lang genug udn in weiten Teilen ohnehin ein Dialog.
die Salome

Weil es Leute gibt, die sich darüber beschweren, wenn ich es nicht tue.
 

naich

Pomme d'or
Registriert
22.11.08
Beiträge
3.082
Du musst besondere Rechte haben, um in fremde Prozesse zu schreiben.

Dann hättest du auch gleich zugeben können, dass es durchaus möglich ist. Anstatt hier rumzumotzen.

Es hat immer noch nicht die geringste Bedeutung, wem dieser Prozess gehört. Zeig mir in deinem Code die Zeile, in dem es auf darauf ankommt, dass die beiden Prozesse einem bestimmten, nämlich demselben User gehören. Es gibt sie nicht. ...

Das hast du schon vor Ewigkeiten geschrieben und ist sicher richtig so. Und das steht hier auch gar nicht mehr zur Debatte. Also spar die den nochmals wiederholenden Text.

Und um nochmal klar zu machen: Dem TE ging es erstmal darum, dass in der 2. Instanz von Mail nur im Fenster ansich copy und paste möglich ist, nicht etwa zwischen den 2 Mail-Instanzen hinweg. Also spielt hier eine Kommunikation zwischen 2 Nutzern erstmal gar keine Rolle.
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Ich habe von Anfang an gesagt, dass es nur um Prozesse geht und nicht um User. Insofern ist da gar nichts geändert.

Eben WEIL es expliziten Code gibt, der User abfragt, beweist dies, dass es nichts mit User zu tun hat. Ich muss das explizit so konzeptionieren.
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Dann hättest du auch gleich zugeben können, dass es durchaus möglich ist. Anstatt hier rumzumotzen.
Ich habe nie gesagt, dass es nicht möglich ist. Ich habe sogar explizit 342862387634287 Mal gesagt, dass es gar keinen Unterschied macht, wem der Prozess gehört.

Derjenige, der für das organisiert muss Root-Redchte haben, bei uns das wäre es da Pasteboard, wenn er verschiedene Speicherbereiche verschiedener Prozesse ansprechen möchte. Dazu ist es immer noch egal, wem der Prozess gehört. Und er benötigt eben root-Rechte und nicht Rechte von User A und B. Das spielt immer noch nicht die geringste Rolle. Und diese Rechte benötigt er bereits für zwei Prozesse von User A.

Und übrigens hatte ich ebenfalls bereits vor Ewigkeiten gesagt, dass es ohnehin gleichgültig ist, weil PBS und Ziel nur lesen.

Das hast du schon vor Ewigkeiten geschrieben und ist sicher richtig so. Und das steht hier auch gar nicht mehr zur Debatte. Also spar die den nochmals wiederholenden Text.

Ich hätte zugeben sollen, was ich richtig gesagt habe!?

Und um nochmal klar zu machen: Dem TE ging es erstmal darum, dass in der 2. Instanz von Mail nur im Fenster ansich copy und paste möglich ist, nicht etwa zwischen den 2 Mail-Instanzen hinweg. Also spielt hier eine Kommunikation zwischen 2 Nutzern erstmal gar keine Rolle.
*seufz* Und wer sagt das die ganze Zeit?

Es spielte aber für ihn eine Rolle, weil er den Vorschlag bekam, die beiden Mail-Instanzen unter verschiedenen Usern laufen zu lassen und er meinte, dass er dann kein C&P hat. Das war für ihn ein Gegenargument, es mit zwei Usern zu probieren.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
… Eben WEIL es expliziten Code gibt, der User abfragt, beweist dies, dass es nichts mit User zu tun hat. Ich muss das explizit so konzeptionieren.

Du mußt gar nichts konzeptionieren. Das hat UNIX schon getan. Ich habe News für Dich: Das ist ein Kernkonzept von Unix: Usertrennung. Unix ist so konzeptioniert. OS X ist so. Das Ding achtet alle naselang darauf, wem was gehört. Das macht es auch Viren so verdammt schwer hier.