Versions Compared

Old Version 2

changes.mady.by.user Tony Johnson

Saved on

compared with

New Version 3

changes.mady.by.user Tony Johnson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

We have not so far succeeded in getting user programs (pipeline client and datacat client) to use oracle wallet. The passwords for theses these programs are currently stored in plain text in the script itself readable by anyone at SLAC, and in the most obvious place for a hacker to look for them. There are two reasons for needing to do this:

  • Oracle wallet is currently only usable with Oracle 10.2. The only installation of oracle 10.2 at SLAC is a 64 bit version, but SLAC has many machines (especially batch machines) still running 32 bit OS. We would need a 32 bit oracle installation to use oracle wallet for end-user programs. <b>This This needs to be checked with Ian<b>Ian.
  • Whether we use oracle wallet or some other mechanism we have no way to give read access only to GLAST collaborators. We need an AFS or NFS group which is maintained and contains all GLAST collaborators/users. <b>Tom Tom says we are working on creating an AFS group</b>group.

We have not succeeded in using oracle roles. There are currently two reasons for this:

  • All of our software currently assumes it is using a particular "default" schema. We have not figured out how to set up oracle connection aliases such that a particular default schema is set automatically when using a role account. So to use roles we would have to change all of our software which is not possible at the current time. Perhaps it is possible to do this using oracle "login scripts" but we have not had time to look into this.
  • Role accounts do not appear to allow one to modify database tables, so even if we get them working we would still need to share passwords to the owner accounts with developers. Need to double-check if this is really true?

Since we have not succeeded in getting roles working we still have to share passwords for all of our service accounts with users, and they still need to embed these passwords in their development environments. Everytime Every time the passwords are changed we need to inform developers and they will need to waste more time updating their configuration files.

...

  • Gives experiments sufficient lead time for such security related changes. This would typically be at least one year.
  • Discusses it detail with the experiment the need for such changes.
  • Ensure that an accurate assessment of manpower required implement changes is established at the outset, including manpower needed to research solutions before deciding on and implementing the chosen solution.
  • Where possible the manpower to implement such security changes should come aqt least in part from SCCS itself, and the . The resulting solutions should be documented and made available to everyone in the lab.