que faire des recommandation oracle [Résolu]

[gold15]

Bonjour
Avec oracle 10 sous windows
Oracle recommande de révoquer pour le groupe PUBLIC les privilèges EXECUTE portant sur des packages importants
Package DBMS_RANDOM UTL_TCP UTL_HTTP UTL_SMTP UTL_FILE

Le faire avec les commandes de type
REVOKE EXECUTE ON "SYS"."DBMS_RANDOM" FROM "PUBLIC";
Fonctionne mais je vois apparaitre alors
5 Objet invalide pour le schémas DMSYS.
9 objet(s) non valide(s) dans le schéma OLAPSYS.

D'ou la question doit on oui ou non prendre en compte les recommandation ?

D'avance merci de toutes pistes

[ojo77]

Le fait de laisser ces packages acessible à des utilisateurs permet d'injecter des données dans la base sans y être autorisé, c'est une faille de sécurité.

Rien n'empêche de redonner les droits sur ces packages aux utilisateurs DMSYS, OLAPSYS directement et de vérouiller ces comptes.

[vinc26]

Pareille j'ai eu des alertes suite au REVOKE
5 Objet invalide pour le schémas DMSYS.
9 objet(s) non valide(s) dans le schéma OLAPSYS.

Faut il faire quelque chose ou pas?

[Heaven93]

invalides après recompilation ?
sinon, tout à fait d'accord avec OJO77. c'est bien de redonner les droits de manière chirurgicale s'ils sont nécessaires
Bonne journée

[laurentschneider]

Envoyé par ojo77

Le fait de laisser ces packages acessible à des utilisateurs permet d'injecter des données dans la base sans y être autorisé, c'est une faille de sécurité.

Pas tout à fait d'accord.

DBMS_RANDOM :

il y a trop de développeurs qui utilisent DBMS_RANDOM pour crypter leurs données et que DBMS_RANDOM ne génère que des nombres pseudo-aléatoire (pour la même SEED, on a toujours la même suite de nombres générés), donc prévisibles. On enlève l'accès au package.
Ca ne fixe aucune faille, ça empêche d'utiliser DBMS_RANDOM à des fins de cryptographies (c'est un peu le serpent qui se mort la queue)

UTL_TCP UTL_HTTP UTL_SMTP:

Mieux vaut configurer le Fine-Grained Access to External Network Services si on employe ces packages. C'est vrai qu'il y a eu des bugs.

UTL_FILE:

Il y a eu trop de dba boiteux qui ont mis utl_file_dir=* ou donner le droit "create any directory" à n'importe qui, donc pour contrer la débilité du dba, Oracle conseille d'enlever le droit execute d'UTL_FILE


Bon, à ta place j'enlèverais ces polices de OEM (dans Metric and Policy settings), plutôt que d'enlever les droits.

Si c'était si critique, Oracle ne donnerait pas ces droit par défaut, non?

[mnitu]

"Other Security Considerations"

[Edit]
Mais, de tout façon ça n'existe qu'à partir de la 11g.
[/Edit]

[laurentschneider]

va pour revoke from public pour les packages réseau

bon, je n'aime pas trop ces 12437 violations dans grid, quand les 99% sont des ports ouverts et des execute sur les packages si dessus.

Warning plutôt que Critical ?

[DROE_78]

il y a eu trop de dba boiteux qui ont mis utl_file_dir=* ou donner le droit "create any directory" à n'importe qui, donc pour contrer la débilité du dba, Oracle conseille d'enlever le droit execute d'UTL_FILE

ca serait cool d’éviter ce genre de propos, ça donne vraiment pas envie de continuer à lire, Expert ou pas

[Waldar]

Au contraire, venant d'un dba je trouve ça plutôt honnête : c'est le plus habilité à critiquer sa profession.

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par Waldar

Au contraire, venant d'un dba je trouve ça plutôt honnête : c'est le plus habilité à critiquer sa profession.

Je suis d'accord.

[laurentschneider]

je pense que boiteux est un peu dur, j'aurais du dire "junior" et/ou "inconscient"

Bon, pour UTL_FILE c'est vrai que l'on peut vraiment faire du dégat, par exemple avec UTL_FILE.FREMOVE...

Mais comme ce sont des droits par défaut, qui sont sur toutes les bases par défaut, j'ai ajouté un MONITORING TEMPLATE par défaut qui exclut ces violations.