9
Oracle 11g - Oracle Label Security - Insert Operation
Habe ein Verständnisproblem bei OLS und hoffe hier auf Hilfe ;)
Hallo zusammen!
Meine Frage bezieht sich auf die INSERT Operation bei Tabellen, die mit Oracle Label Security geschützt sind.
Quelle für die Regeln der Zugriffskontrolle:
http://www.stanford.edu/dept/itss/docs/oracle/10g/network.101/b10774.pd ...
Auf S. 76/338 sind die Lese-Zugriffsrechte erläutert.
Auf S. 78/338 sind die Schreib-Zugriffsrechte erläutert.
Die Schreib-Zugriffsrechte umfassen Update-, Insert- und Delete- Operationen.
Sowohl beim Lese- als auch beim Schreibzugriff wird das Data-Level mit dem User-Level verglichen.
Bei Select-, Update- und Delete- Operationen kann ich das verstehen, weil die Label ja schon vorhanden sind.
Aber wie kann ich bei einer Insert-Operation das Data-Level mit dem User-Level vergleichen, wenn noch gar keine Zeile geschrieben ist, sondern erst mit diesem Befehl geschrieben werden soll?
Haben die Tabellen dann schon ein Standard-Label für alle Zeilen und dieses wird geprüft?
Also mein Verständnis-Problem liegt daran, dass ich nicht weiß wie man bei der Insert-Operation die Regeln von S.78/338 anwenden kann, wenn die Zeile gerade erst geschrieben werden soll und somit kein Label zum vergleichen vorhanden ist.
Vielen Dank für eine Antwort!!
Meine Frage bezieht sich auf die INSERT Operation bei Tabellen, die mit Oracle Label Security geschützt sind.
Quelle für die Regeln der Zugriffskontrolle:
http://www.stanford.edu/dept/itss/docs/oracle/10g/network.101/b10774.pd ...
Auf S. 76/338 sind die Lese-Zugriffsrechte erläutert.
Auf S. 78/338 sind die Schreib-Zugriffsrechte erläutert.
Die Schreib-Zugriffsrechte umfassen Update-, Insert- und Delete- Operationen.
Sowohl beim Lese- als auch beim Schreibzugriff wird das Data-Level mit dem User-Level verglichen.
Bei Select-, Update- und Delete- Operationen kann ich das verstehen, weil die Label ja schon vorhanden sind.
Aber wie kann ich bei einer Insert-Operation das Data-Level mit dem User-Level vergleichen, wenn noch gar keine Zeile geschrieben ist, sondern erst mit diesem Befehl geschrieben werden soll?
Haben die Tabellen dann schon ein Standard-Label für alle Zeilen und dieses wird geprüft?
Also mein Verständnis-Problem liegt daran, dass ich nicht weiß wie man bei der Insert-Operation die Regeln von S.78/338 anwenden kann, wenn die Zeile gerade erst geschrieben werden soll und somit kein Label zum vergleichen vorhanden ist.
Vielen Dank für eine Antwort!!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 165439
Url: https://administrator.de/contentid/165439
Printed on: April 24, 2024 at 20:04 o'clock
9 Comments
Latest comment
Moin 8sifi5,
leider kann ausser dir niemand das verlinkte PDF-Dokument öffnen, weil der Link leider etwas verstümmelt ist - biite korrigiere den doch mal
Dann können wir an dort konkret formulierten Unsauberkeiten aufseten.
Unabhängig davon - du schreibst:
Beide real existierenden Implementierungen der Mandatory Access Control - laso die Label Based Access Control (LBAC) bei der Db2 9.1 LUW oder die Oracle-Variante Label Security seit der 10.2 und jetzt seit der 11.2 wohl marktreif basieren darauf, dass die "Labels" (auf die du dein Hauptaugenmerk zu richten scheinst) eigentlich erst der zweite oder dritte Schritt sind.
Viel früher im Konzept/Design sind die Security Policies, also Sicherheitsrichtlinien, die den Datenbankobjekten (z.B. Tabellen, Rows oder Columns) zugeordnet werden.
Je nach Implementierung kann schon beim INSERT die Prüfung auf "Hat der anfordernde User das volle Recht auf die komplette Row?" schon ergeben: "Njet".
So dass sich die Frage nach "default-SecLabel-Werten" gar nicht erst stellt.
Aber lass uns konkret weiterplaudern, wenn der Link oben berichtigt ist (oder du die relevante Passage gepostet hast).
Grüße
Biber
leider kann ausser dir niemand das verlinkte PDF-Dokument öffnen, weil der Link leider etwas verstümmelt ist - biite korrigiere den doch mal
Dann können wir an dort konkret formulierten Unsauberkeiten aufseten.
Unabhängig davon - du schreibst:
Haben die Tabellen dann schon ein Standard-Label für alle Zeilen und dieses wird geprüft?
.Beide real existierenden Implementierungen der Mandatory Access Control - laso die Label Based Access Control (LBAC) bei der Db2 9.1 LUW oder die Oracle-Variante Label Security seit der 10.2 und jetzt seit der 11.2 wohl marktreif basieren darauf, dass die "Labels" (auf die du dein Hauptaugenmerk zu richten scheinst) eigentlich erst der zweite oder dritte Schritt sind.
Viel früher im Konzept/Design sind die Security Policies, also Sicherheitsrichtlinien, die den Datenbankobjekten (z.B. Tabellen, Rows oder Columns) zugeordnet werden.
Je nach Implementierung kann schon beim INSERT die Prüfung auf "Hat der anfordernde User das volle Recht auf die komplette Row?" schon ergeben: "Njet".
So dass sich die Frage nach "default-SecLabel-Werten" gar nicht erst stellt.
Aber lass uns konkret weiterplaudern, wenn der Link oben berichtigt ist (oder du die relevante Passage gepostet hast).
Grüße
Biber
Hallo Biber,
Danke für den Hinweis. Link wurde korrigiert.
Bei Oracle kann man natürlich auch direkt mittels GRANT auf Tabellen oder Sichten Rechte vergeben.
Und was Du mit Sicherheitspolicies meinst, ist glaub ich das "Virtual Private Database" Konzept von Oracle, richtig?
Ich möchte aber bei meinem Beispiel von einer einfachen Tabelle ausgehen, bei der jede Person mittels GRANT-Berechtigung Lese- und Schreibzugriff besitzt. Erst danach greifen ja die OLS Rechte.
Zudem soll auf die Tabelle OLS angewendet worden sein, d.h. die Tabelle besitzt eine eigene Label-Spalte und in jeder Zeile wird ein Berechtigungs-Label in diese Spalte eingefügt.
Und nun bin ich genau bei meinem Problem aus Post 1:
Wenn das Label schon vorhanden ist kann ich darauf basierend die Zugriffsrechte bei SELECT, UPDATE und DELETE bestimmen.
Aber wie kann ich die Regel auf S. 78/338 beim Schreibzugriff mit INSERT anwenden, wenn noch kein Label vorhanden ist? (außer es existiert ein Default-Label - was ich eben nicht weiß)
Danke für Deine Antwort
Danke für den Hinweis. Link wurde korrigiert.
Bei Oracle kann man natürlich auch direkt mittels GRANT auf Tabellen oder Sichten Rechte vergeben.
Und was Du mit Sicherheitspolicies meinst, ist glaub ich das "Virtual Private Database" Konzept von Oracle, richtig?
Ich möchte aber bei meinem Beispiel von einer einfachen Tabelle ausgehen, bei der jede Person mittels GRANT-Berechtigung Lese- und Schreibzugriff besitzt. Erst danach greifen ja die OLS Rechte.
Zudem soll auf die Tabelle OLS angewendet worden sein, d.h. die Tabelle besitzt eine eigene Label-Spalte und in jeder Zeile wird ein Berechtigungs-Label in diese Spalte eingefügt.
Und nun bin ich genau bei meinem Problem aus Post 1:
Wenn das Label schon vorhanden ist kann ich darauf basierend die Zugriffsrechte bei SELECT, UPDATE und DELETE bestimmen.
Aber wie kann ich die Regel auf S. 78/338 beim Schreibzugriff mit INSERT anwenden, wenn noch kein Label vorhanden ist? (außer es existiert ein Default-Label - was ich eben nicht weiß)
Danke für Deine Antwort
Moin 8sifi5,
Merci.
Die GRANTerei ist ja der klassische Ansatz, also das flapsig Discretionary Access Control (DAC) genannte Konzept.
Wenn wir mal die Schörkel weglassen, dann steckt an Schmalz doch nur drin, dass ein Objekt unter der Kontrolle seines Eigentümers/Erstellers/OWNERs steht.
Der OWNER kann -das ist die gute Nachricht- Berechtigungen auf das Objekt vergeben oder widerrufen, aber -schlechte Nachricht- eben nur auf dieser Objekterstell-Ebene (Tabelle oder View).
Nicht auf Ebene Zeilen oder Spalten (außer dem radikalen Ausblenden von diesen über Views oder WHERE-Bedingungen)
Nicht auf Ebene Dateninhalte, also in Abhängigkeit von Datenwerten.
Von diesem DAC-Konzept rede ich nicht - das liegt selbstredend immer mit drunter..
Oracle ist ja bezüglich Sicherheitsfunktionen nie ganz sauber geblieben und auch nie konsequent mit den Buzzwords.
Neben VPD geistern ja auch noch Fine Grained Access Control (FGAC) oder Row Level Security (RLS) durch die White Papers.
Was du hier diskutierst ist ja die so genannte OLS (Oracle Label Security) die -ja, ACK- auf VPD-Technologie basiert.
Die wiederum wird gepusht aus vier Gründen:
Grüße
Biber
Merci.
Bei Oracle kann man natürlich auch direkt mittels GRANT auf Tabellen oder Sichten Rechte vergeben.
Von irgendeinem GRANT habe ich zu keinem Zeitpunkt geschrieben und auch nicht daran gedacht.Die GRANTerei ist ja der klassische Ansatz, also das flapsig Discretionary Access Control (DAC) genannte Konzept.
Wenn wir mal die Schörkel weglassen, dann steckt an Schmalz doch nur drin, dass ein Objekt unter der Kontrolle seines Eigentümers/Erstellers/OWNERs steht.
Der OWNER kann -das ist die gute Nachricht- Berechtigungen auf das Objekt vergeben oder widerrufen, aber -schlechte Nachricht- eben nur auf dieser Objekterstell-Ebene (Tabelle oder View).
Nicht auf Ebene Zeilen oder Spalten (außer dem radikalen Ausblenden von diesen über Views oder WHERE-Bedingungen)
Nicht auf Ebene Dateninhalte, also in Abhängigkeit von Datenwerten.
Von diesem DAC-Konzept rede ich nicht - das liegt selbstredend immer mit drunter..
Und was Du mit Sicherheitspolicies meinst, ist glaub ich das "Virtual Private Database" Konzept von Oracle, richtig?
Der zweite Satz - ob ich mit Sicherheitspolicies das VPD-Konzept meine. auch ja nee.Oracle ist ja bezüglich Sicherheitsfunktionen nie ganz sauber geblieben und auch nie konsequent mit den Buzzwords.
Neben VPD geistern ja auch noch Fine Grained Access Control (FGAC) oder Row Level Security (RLS) durch die White Papers.
Was du hier diskutierst ist ja die so genannte OLS (Oracle Label Security) die -ja, ACK- auf VPD-Technologie basiert.
Die wiederum wird gepusht aus vier Gründen:
- lässt sich nachträglich dranflanschen
- keine Individualprogrammierung nötig
- für die Verwaltung der Levels/Compartments/Groups ist ein Deppen-GUI-Tool vorhanden (OPM Oracle Policies Manager)
- und der Coup de Grace - Oracle hat das Akzeptanzproblem bei der DBA-Lobby für dieses Sicherheitskonzept recht interessant gelöst: bei Oracle gibt es zwar auch eine neue Rolle LBAC_DBA für den Sicherheitsadministrator und eine neue UserID LBACSYS für den OWNER - aber der SYSDBA steht immer oberhalb der Label Security. SYSDBAs haben also uneingeschränkten Zugriff auch auf alle SecLabel-geschützten Daten.Was natürlich das Konzept ad absurdum führt. IBM/DB2 ist da konsequenter.
Ich möchte aber bei meinem Beispiel von einer einfachen Tabelle ausgehen, bei der jede Person mittels GRANT-Berechtigung
Lese- und Schreibzugriff besitzt. Erst danach greifen ja die OLS Rechte.
Zudem soll auf die Tabelle OLS angewendet worden sein, d.h. die Tabelle besitzt eine eigene Label-Spalte und in jeder Zeile wird
ein Berechtigungs-Label in diese Spalte eingefügt.
Und nun bin ich genau bei meinem Problem aus Post 1:
Wenn das Label schon vorhanden ist kann ich darauf basierend die Zugriffsrechte bei SELECT, UPDATE und DELETE bestimmen.
Aber wie kann ich die Regel auf S. 78/338 beim Schreibzugriff mit INSERT anwenden, wenn noch kein Label vorhanden ist?
(außer es existiert ein Default-Label - was ich eben nicht weiß)
Dazu lies bitte auf Seite 138 in dem PDF:Lese- und Schreibzugriff besitzt. Erst danach greifen ja die OLS Rechte.
Zudem soll auf die Tabelle OLS angewendet worden sein, d.h. die Tabelle besitzt eine eigene Label-Spalte und in jeder Zeile wird
ein Berechtigungs-Label in diese Spalte eingefügt.
Und nun bin ich genau bei meinem Problem aus Post 1:
Wenn das Label schon vorhanden ist kann ich darauf basierend die Zugriffsrechte bei SELECT, UPDATE und DELETE bestimmen.
Aber wie kann ich die Regel auf S. 78/338 beim Schreibzugriff mit INSERT anwenden, wenn noch kein Label vorhanden ist?
(außer es existiert ein Default-Label - was ich eben nicht weiß)
LABEL_DEFAULT: Using the Session's Default Row Label
A user can update a row without specifying a label value, because the updated row
uses its original label. However, to insert a new row, the user must supply a valid
label unless a labeling function is in force or LABEL_DEFAULT applies for this
table. LABEL_DEFAULT causes the user's session default row label to be used as
the new row label.
If neither LABEL_DEFAULT nor a labeling function is in force and the user
attempts to INSERT a row, an error occurs.
Note that any labeling function in force on a table overrides the LABEL_DEFAULT option
A user can update a row without specifying a label value, because the updated row
uses its original label. However, to insert a new row, the user must supply a valid
label unless a labeling function is in force or LABEL_DEFAULT applies for this
table. LABEL_DEFAULT causes the user's session default row label to be used as
the new row label.
If neither LABEL_DEFAULT nor a labeling function is in force and the user
attempts to INSERT a row, an error occurs.
Note that any labeling function in force on a table overrides the LABEL_DEFAULT option
Grüße
Biber
Zitat von @Biber:
Dazu lies bitte auf Seite 138 in dem PDF:
> LABEL_DEFAULT: Using the Session's Default Row Label
> A user can update a row without specifying a label value, because the updated row
> uses its original label. However, to insert a new row, the user must supply a valid
> label unless a labeling function is in force or LABEL_DEFAULT applies for this
> table. LABEL_DEFAULT causes the user's session default row label to be used as
> the new row label.
> If neither LABEL_DEFAULT nor a labeling function is in force and the user
> attempts to INSERT a row, an error occurs.
> Note that any labeling function in force on a table overrides the LABEL_DEFAULT option
Dazu lies bitte auf Seite 138 in dem PDF:
> LABEL_DEFAULT: Using the Session's Default Row Label
> A user can update a row without specifying a label value, because the updated row
> uses its original label. However, to insert a new row, the user must supply a valid
> label unless a labeling function is in force or LABEL_DEFAULT applies for this
> table. LABEL_DEFAULT causes the user's session default row label to be used as
> the new row label.
> If neither LABEL_DEFAULT nor a labeling function is in force and the user
> attempts to INSERT a row, an error occurs.
> Note that any labeling function in force on a table overrides the LABEL_DEFAULT option
Bei meinem PDF steht das auf S. 185 aber das tut ja nichts zur Sache. Danke fürs raussuchen.
Also ich verstehe das so, dass entweder ein neues Label angegeben werden muss, oder bei der Option LABEL_DEFAULT das Session-Label des Users verwendet wird.
Angenommen die Option LABEL_DEFAULT ist aktiv, dann schreibt der User immer mit seinem Session-Label und somit wäre der Schreibzugriff immer erlaubt. Und auch solange er manuell ein gültiges Label verwendet (was der No-Write-Down-Regel entspricht) dürfte er immer schreiben. Ist das tatsächlich so?
Schönen Sonntag!
Moin 8sifi5,
sorry wegen der falschen Seitenzahl - keine Ahnung, wie ich die verdreht habe.
Zu deiner Nachfrage: Ja, ich verstehe das OLS-Konzept an dieser Stelle genau wie du.
Falls denn ein INSERT-Attempt durch einen User angestossen wird und KEIN "manuell gesetztes" Label mitgegeben wird, dann würde der/die/das LABEL_DEFAULT des Users als Maßstab aller Dinge herangezogen. Also die Werte, die du über den View DBA_SA_USER_LEVELS einsehen kannst (Running gag II: Lustigerweise darfst du das mit DBA-Rechten -für mich ein Treppenwitz der Implementierung, s.o)
Auf S,178 (also auf meiner Seite 178 *gg) ist dieser View DBA_SA_USER_LEVELS beschrieben:
Grüße
Biber
sorry wegen der falschen Seitenzahl - keine Ahnung, wie ich die verdreht habe.
Zu deiner Nachfrage: Ja, ich verstehe das OLS-Konzept an dieser Stelle genau wie du.
Falls denn ein INSERT-Attempt durch einen User angestossen wird und KEIN "manuell gesetztes" Label mitgegeben wird, dann würde der/die/das LABEL_DEFAULT des Users als Maßstab aller Dinge herangezogen. Also die Werte, die du über den View DBA_SA_USER_LEVELS einsehen kannst (Running gag II: Lustigerweise darfst du das mit DBA-Rechten -für mich ein Treppenwitz der Implementierung, s.o)
Auf S,178 (also auf meiner Seite 178 *gg) ist dieser View DBA_SA_USER_LEVELS beschrieben:
Displays the levels assigned to the user:
minimum level, maximum level, default level,
and level for the row label
minimum level, maximum level, default level,
and level for the row label
Grüße
Biber
Morgen Biber,
Danke nochmal für Deine Antwort.
Die INSERT-Operation ist mir nun klar. Dafür habe ich nun bei der UPDATE-Operation noch zwei Unklarheiten:
1. Wenn ich eine Zeile per UPDATE-Operation updaten möchte, welches Data-Label ist dann relevant - das vorhandene in der Zeile oder das neue in der UPDATE-Operation?
Bisher dachte ich, dass das vorhandene Data-Label in der Zeile mit dem User-Label verglichen werden würde. Aber stimmt das denn auch, wenn man durch die Update-Operation ja praktisch ein neues Label (z.B. das eigene DEFAULT_LABEL) übergibt.
2. Bzw. wird durch eine UPDATE-Operation zwingend das Label einer Zeile geändert oder bleibt das Label der Zeile evtl. gleich?
Viele Grüße zurück
Danke nochmal für Deine Antwort.
Die INSERT-Operation ist mir nun klar. Dafür habe ich nun bei der UPDATE-Operation noch zwei Unklarheiten:
1. Wenn ich eine Zeile per UPDATE-Operation updaten möchte, welches Data-Label ist dann relevant - das vorhandene in der Zeile oder das neue in der UPDATE-Operation?
Bisher dachte ich, dass das vorhandene Data-Label in der Zeile mit dem User-Label verglichen werden würde. Aber stimmt das denn auch, wenn man durch die Update-Operation ja praktisch ein neues Label (z.B. das eigene DEFAULT_LABEL) übergibt.
2. Bzw. wird durch eine UPDATE-Operation zwingend das Label einer Zeile geändert oder bleibt das Label der Zeile evtl. gleich?
Viele Grüße zurück
Moin 8sifi5,
für eine Antwort darauf schau ich jetzt mal nicht in irgendwelche schlauen Oracle White Paper, das muss so gehen.
Denn dieses gibt doch die erforderlichen Mindestberechtigungen des Änderers an.
Der Benutzer KÖNNTE natürlich ein Superduperultra-Rechteinhaber mit ALLEN-ABER-AUCH-ALLEN Rechten sein.
Wenn nun dessen "User-Label-Rechte" für diesen geänderten Satz übernommen werden würden - wer sollte das jemals ändern dürfen?
Ausgenommen dieser Superduperultra-Rechteinhaber selbst. Und natürlich seine Frau.
Grüße
Biber
für eine Antwort darauf schau ich jetzt mal nicht in irgendwelche schlauen Oracle White Paper, das muss so gehen.
Zitat von @8sifi5:
Die INSERT-Operation ist mir nun klar. Dafür habe ich nun bei der UPDATE-Operation noch zwei Unklarheiten:
1. Wenn ich eine Zeile per UPDATE-Operation updaten möchte, welches Data-Label ist dann relevant - das vorhandene in der
Zeile oder das neue in der UPDATE-Operation?
Beide natürlich.Die INSERT-Operation ist mir nun klar. Dafür habe ich nun bei der UPDATE-Operation noch zwei Unklarheiten:
1. Wenn ich eine Zeile per UPDATE-Operation updaten möchte, welches Data-Label ist dann relevant - das vorhandene in der
Zeile oder das neue in der UPDATE-Operation?
Bisher dachte ich, dass das vorhandene Data-Label in der Zeile mit dem User-Label verglichen werden würde.
Ich auch.Aber stimmt das denn auch, wenn man durch die Update-Operation ja praktisch ein neues Label (z.B. das eigene DEFAULT_LABEL) übergibt.
2. Bzw. wird durch eine UPDATE-Operation zwingend das Label einer Zeile geändert oder bleibt das Label der Zeile evtl. gleich?
Das "vorhandene LABEL der Zeile" bleibt natürlich.2. Bzw. wird durch eine UPDATE-Operation zwingend das Label einer Zeile geändert oder bleibt das Label der Zeile evtl. gleich?
Denn dieses gibt doch die erforderlichen Mindestberechtigungen des Änderers an.
Der Benutzer KÖNNTE natürlich ein Superduperultra-Rechteinhaber mit ALLEN-ABER-AUCH-ALLEN Rechten sein.
Wenn nun dessen "User-Label-Rechte" für diesen geänderten Satz übernommen werden würden - wer sollte das jemals ändern dürfen?
Ausgenommen dieser Superduperultra-Rechteinhaber selbst. Und natürlich seine Frau.
Grüße
Biber
Zitat von @Biber:
Moin 8sifi5,
für eine Antwort darauf schau ich jetzt mal nicht in irgendwelche schlauen oracle White Paper, das muss so gehen.
> Zitat von @8sifi5:
> ----
> Die INSERT-Operation ist mir nun klar. Dafür habe ich nun bei der UPDATE-Operation noch zwei Unklarheiten:
> 1. Wenn ich eine Zeile per UPDATE-Operation updaten möchte, welches Data-Label ist dann relevant - das vorhandene in
der
> Zeile oder das neue in der UPDATE-Operation?
Beide natürlich.
Moin 8sifi5,
für eine Antwort darauf schau ich jetzt mal nicht in irgendwelche schlauen oracle White Paper, das muss so gehen.
> Zitat von @8sifi5:
> ----
> Die INSERT-Operation ist mir nun klar. Dafür habe ich nun bei der UPDATE-Operation noch zwei Unklarheiten:
> 1. Wenn ich eine Zeile per UPDATE-Operation updaten möchte, welches Data-Label ist dann relevant - das vorhandene in
der
> Zeile oder das neue in der UPDATE-Operation?
Beide natürlich.
Ich mach mal ein Beispiel mit zwei Fällen dazu - angenommen eine Tabelle MyTable mit drei Spalten (ID, Info, Label).
Inhalt in Tabelle:
1|"Meine Information" | "Label_secret"
Dann zwei verschiedene Updates:
Fall 1:
Update MyTable set Info="Meine neue Info", Label="Label_topsecret" where ID = 1
=> Geht das so? Würde dann geprüft werden ob der User "Label_secret" UND "Label_topsecret" schreiben darf? Und würde das Label hier geändert werden?
Fall 2:
Update MyTable set Info="Meine neue Info" where ID = 1
=> Geht das so? Würde dann nur geprüft werden ob man "Label_secret" schreiben darf? Das Label in der Zeile würde, entsprechend deiner Aussage zur zweiten Frage, unverändert bleiben (unabhängig von User-Label)?
> Bisher dachte ich, dass das vorhandene Data-Label in der Zeile mit dem User-Label verglichen werden würde.
Ich auch.
> Aber stimmt das denn auch, wenn man durch die Update-Operation ja praktisch ein neues Label (z.B. das eigene DEFAULT_LABEL)
übergibt.
> 2. Bzw. wird durch eine UPDATE-Operation zwingend das Label einer Zeile geändert oder bleibt das Label der Zeile evtl.
gleich?
Das "vorhandene LABEL der Zeile" bleibt natürlich.
...Ich auch.
> Aber stimmt das denn auch, wenn man durch die Update-Operation ja praktisch ein neues Label (z.B. das eigene DEFAULT_LABEL)
übergibt.
> 2. Bzw. wird durch eine UPDATE-Operation zwingend das Label einer Zeile geändert oder bleibt das Label der Zeile evtl.
gleich?
Das "vorhandene LABEL der Zeile" bleibt natürlich.
Grüße
Biber
Grüße
Moin 8sifi5,
ich sach ma so:
Ein Unterschied der Implementierung von DB2 und Oracle ist, dass DB2 eine Fehlermeldung/einen handlebaren Errorcode ausgibt,
wenn ein User auf eine Spalte zugreift, auf die er nicht berechtigt ist.
Oracle gibt einfach keine Zeilen aus (SQLCODE +1403), wenn der Benutzer nicht autorisiert für eine Spalte ist.
--> Wenn jetzt dein Feld "Info" geändert würde auf neuen Inhalt und dabei automatisch das SecLabel für die ganze Zeile geändert werden würde auf "top secret"--> dann könnten alle Nicht-"top secret"-Berechtigten diese Zeile nie wieder sehen.
Egal welches Feld dieser Zeile angefasst wird.
Das wäre zwar auch eine interessante Form der Implementierung, aber daran glaube ich nicht.
Würde doch bedeuten, dass wenn ein "top secret"-Label-Träger ein
Das würde auch bedeuten, dass geschützte Tabellen immer "geschützter" werden im Lauf der Zeit
-> sobald ein "top secret"-User da irgendetwas, irgendein Bemerkungsfeld bearbeitet, würde die Sicherheitsstufe dieser Zeile/dieses Datensatzes hochgesetzt.
Glaub ich nicht - probiere es doch mal aus.
Grüße
Biber
ich sach ma so:
Ein Unterschied der Implementierung von DB2 und Oracle ist, dass DB2 eine Fehlermeldung/einen handlebaren Errorcode ausgibt,
wenn ein User auf eine Spalte zugreift, auf die er nicht berechtigt ist.
Oracle gibt einfach keine Zeilen aus (SQLCODE +1403), wenn der Benutzer nicht autorisiert für eine Spalte ist.
--> Wenn jetzt dein Feld "Info" geändert würde auf neuen Inhalt und dabei automatisch das SecLabel für die ganze Zeile geändert werden würde auf "top secret"--> dann könnten alle Nicht-"top secret"-Berechtigten diese Zeile nie wieder sehen.
Egal welches Feld dieser Zeile angefasst wird.
Das wäre zwar auch eine interessante Form der Implementierung, aber daran glaube ich nicht.
Würde doch bedeuten, dass wenn ein "top secret"-Label-Träger ein
UPDATE MyTable set Info=Info where (1 = 1)
...ausführt, also alle Sätze/Feld Info mit dem updatet, was vorher auch drin stand, dass dann alle Zeilen auf "top secret" stehen.Das würde auch bedeuten, dass geschützte Tabellen immer "geschützter" werden im Lauf der Zeit
-> sobald ein "top secret"-User da irgendetwas, irgendein Bemerkungsfeld bearbeitet, würde die Sicherheitsstufe dieser Zeile/dieses Datensatzes hochgesetzt.
Glaub ich nicht - probiere es doch mal aus.
Grüße
Biber
