Sicherheitslücke *ALLOBJ

[Fuerchau]

Leider gibt es immer wieder Benutzer oder Softwarehäuser, die als Sonderberechtigung *ALLOBJ haben wollen.

Dies ist eine absolute Sicherheitslücke, da man damit alle Türen aufmacht !

Selbst wenn das Userprofil nur Klasse *PGMR ist, kann ich mein Profil problemlos auf *SECOFR anheben.

Probierts einfach aus:

ADDJOBSCDE JOB(TEST) CMD(CHGUSRPRF USRPRF(FUERCHAU) USRCLS(*SECOFR) SPCAUT(*USRCLS))FRQ(*ONCE) USER(QSECOFR)

Durch die Berechtigung *ALLOBJ kann ich Job's unter einem anderen Profil starten.
Im SBMJOB ist eine Bremse eingebaut, die höhere Profile nicht erlaubt, aber was ist denn ADDJOBSCDE anderes als ein verkappter SBMJOB ?
Und durch die Angabe FRQ(*ONCE) wird der Job nunmal auch sofort ausgeführt.

Auch das Sperren der Kommando-Zeile bringt nichts, wenn ich z.B. PDM ausführen darf.
Oder ich schreibe ein kleines Programm dass obigen Befehl durchführt.
Usw., usw., usw. ...

[malzusrex]

Hallo Fuerchau,

also bei uns hat der QSECOFR für *PUBLIC = *EXCLUDE, und somit funks bei uns nicht, allerdings hatte ich noch nen user mit *SECOFR und damit gings

Grüsserle Ronald

[Sven Schneider]

Hallo Fuerchau, malzusrex,

ab Security-Level 40 besteht diese Problem eigentlich nicht mehr.
D.h. wenn ich in einer JOBD oder mit ADDJOBSCDE einen anderen Benutzer eintrage, dann muß ich auch Rechte an dem Objekt *USRPRF dieses Benutzers haben, sonst läuft der Job nicht.

Und in der Regel steht bei QSECOFR *PUBLIC auf *EXCLUDE.

Sven


[Dieser Beitrag wurde von Sven Schneider am 04. April 2003 editiert.]

[Fuerchau]

Auch bei mir steht der QSECOFR auf PUBLIC(*EXCLUDE) und trotzdem gings !

Das Problem ist die Sonderberechtigung *ALLOBJ !

[Sven Schneider]

Dann ist es auch kein Sicherheitsproblem, *ALLOBJ kann immer!!! alles, auch wenn beim Objekt *PUBLIC auf *EXCLUDE steht.
Und wenn ich *ALLOBJ habe muß der Job auch nicht unter einem anderen Benutzer laufen, denn ich hab' ja schon alle Rechte.

Niemand, sollte bzw. muß im produktiven Einsatz mit einem Profile mit *ALLOBJ-Rechten arbeiten. Für die jeweiligen Funktionen gibt es deswegen ja auch die Special-Authoritys.

sven

[Fuerchau]

Dem kann ich ja nur zustimmen, Sven, aber:

Warum kann ich keinen SBMJOB unter QSECOFR von meinem *ALLOBJ-Profil machen aber einen indirekten SBMJOB über ADDJOBSCDE ?

D.h., *ALLOBJ darf zwar viel, aber noch nicht alles. Dies liegt an den SPCAUT des Profiles und die kann ich zwar einschränken aber nach meiner Methode kann ich die Einschränkung jederzeit wieder aufheben !

[Sven Schneider]

Hallo Fürchau,
weil das so von IBM definiert wurde.
Siehe Beschreibung zu MSGID CPD1617.

Und nochmal; ich muß Rechte am Objekt *USRPRF QSECOFR haben, damit ich QSECOFR im ADDJOBSCDE verwenden kann.
Zur Laufzeit wird dann noch einmal geprüft ob ich Rechte am Profilobjekt QSECOFR habe.
(für den Jobs-Scheduler gilt dies auch bei Securtiy-Level 30, im Gegensatz zur Angabe in der JOBD)

Sven

[Fuerchau]

Auch hier nochmal ergänzt:
Getestet auf V4R5 und V5R1,
QSECOFR steht auf *PUBLIC *EXCLUDE
Mein Profil als QPGMR aber mit *ALLOBJ
ADDJOBSCDE funktionierte bei mir auf Anhieb !

[Sven Schneider]

Jetzt versteh ich das Problem :

Es geht hier eigentlich um den CMD CHGJOBCDE.
Dieser steht standardmäßig nicht auf *PUBLIC *EXCLUDE.
Also noch einmal: QPGMR mit SPCAUT *ALLOBJ erstellt einen Scheduler-Entrag mit USER(QSECOFR). *USRPRF-Objekt QSECOFR steht auf *PUBLIC EXCLUDE, QPGMR darf QSECOFR beim ADDJOBSCDE aber verwenden, weil er *ALLOBJ hat. - Im Gegensatz zu SMBJOB oder CRTJOBD, wo u.a. QSECOFR generell nicht erlaubt ist.
Das ist aber noch kein Sicherheitsproblem, sondern so gewollt.

Jetzt das eigentliche Sicherheitsproblem :
Jeder User, welcher den Command CHGJOBSCDE ausführen kann und SPCAUT *JOBCTL hat, darf bei einem solchen Scheduler Eintrag, z.B. Datum und Zeit ändern und damit einen Job ändern/ausführen, den er eigentlich gar nicht geplant hat.
Aber auch das ist in http://as400bks.rochester.ibm.com/is...5/c4153026.pdf ab Seite 372 beschrieben.

Sven


[Dieser Beitrag wurde von Sven Schneider am 07. April 2003 editiert.]