die Seilerwerks

This past week has been spent packaging and re-installing some “legacy” SQL reporting scripts. Since before my time here, these scripts have been run out of the oracle OS user’s home directory, running as the oracle user, scheduled in the oracle user’s crontab. It’s been a security bug crawling under my skin for some time now, and I should have fixed it a long time ago. Giving developers (or any non-DBA) access to the oracle OS user means giving them the ability to start or shutdown the instance(s) , and even drop the database if they knew the commands.

Besides the security concerns, these reports were not in our CVS and had no installation package. We create RPMs of all of our in-house software that goes onto our RHEL servers, which makes system administration a LOT easier.

So in the end, the shell and SQL files will be in CVS, have a proper installation method and be inventoried in the RPM database on those machines, and will have their own cron file in /etc/cron.d running as a non-privileged user.

There’s still a lot to be done before I’m satisfied from a security perspective, but it’s nice to get these out of the way.

Update: An added bonus is finding out that some of the scripts are obsolete and can just be taken out!

It’s come up before, but it had been so long that I had nearly forgotten it. “It” is the serious permissions lockdown after installing Oracle RDBMS >= 9i. Someone brought it up on the MADLUG list earlier this year, and I vaguely remembered that it was fixed in Oracle 10g 10.2.0.2. What I had forgotten was that it was fixed in the form of a script that needed to be run post-install.

I should say “fixed” because it’s only a problem if you want non-oracle/oinstall users to use utilities like sqlplus locally. Not totally unheard-of by any means, but some people really lock down their servers, and would prefer the tight perms.

Anyway, the script is $ORACLE_HOME/install/changePerm.sh, and it will loosen things up for normal OS users.

Originally here, via Schneier.

There is never, NEVER, N E V E R a reason to store passwords as clear text in a database. No matter how convenient it is for your own personal preference.

Any aspiring application developers reading this: NEVER. Salt-n-hash is such an easy thing to do in most any language now, and you won’t be publicly ridiculed like spez is now.

Got some IMs from one of my devs today including links to articles about Oracle proxy users. The IT-eye articles are very nice, and the asktom article just provides some tkyte flavor to it all. The obvious and immediate benefit is for web applications that would normally log in as one application users, with many virtual users contained in some application-specific authentication and privilege system. Proxy users gives you the privilege/role system of having real Oracle database users, and tightens up security by stripping all privileges away from the “application user” except for CREATE SESSION.

It also gives you an outlet for authenticating your users. In my case I could have my application do any type of authentication I would want, say to our MS Active Directory setup, and if that succeeds, make the call to proxy as that user in Oracle. The important thing to note is that the actual user’s password in Oracle is never used and never needs to be known.