Hi,
By reporting the process status with ps, any Unix user will see the command line arguments
#ps -ef
UID PID PPID C STIME TTY TIME CMD
lsc 13837 13825 0 May 11 pts/17 0:01 -ksh
oracle 4698 6294 0 12:00:40 ? 0:00 sqlplus -s system/manager
appluser 4229 4062 0 12:00:03 ? 0:00 sqlldr scott/tiger

So this is a security issue.
1.How the password should not be stored in a shell environment variable

What version of Oracle are you using? ... how about using Oracle Wallet?


cheers

How do you think that the system knows that the data that you submit contains a password? For the system it's just a bunch of arguments.

So my guess is that it needs to be solved at the application level (sqlplus, sqlldr) and that you can not solve it at the system level without "hacking" the ps command. You can e.g. create a ps-script that ignores the -f option. But on my Slackware 10.1 box, man ps states that ps reads /proc and when I (as a normal user) start digging in there I will still find the full commandline.

As an aside, it's possible on FreeBSD systems to hide other users' processes via a sysctl MIB (security.bsd.see_other_uids). Very cool feature, and I wish there were something comparable in the Linux world.

Anyway, that's neither here nor there. I agree that OP will need to solve this at the application level. The exact way to solve it depends on the app. (I've worked around a similar sqlplus issue by going so far as to hardcode auth credentials in a C program.)

How the system "knows"/sees/interpretes things isn't the point. It's about the act of leaking passwords.


Cludges like that should not be offered unless there's no alternative. Anyone know you can easily bypass scripts like that and besides it's not a best practice for polluting the system with more and unnecessary maintenance items.


That shouldn't need to be presented as "just an aside" IMHO: as a type of solution non-kludgy privilege separation definately is valid. And actually there is: denying UIDs to see other users processes is one of the features of GRSecurity. Of course that requires kernel patching and compilation or using a distribution that provides stock kernels patched with it like for instance Gentoo.


Working with Oracle means having access to rather large knowledge bases all over the 'net. Different posts / pages offer different options. See for instance http://www.orafaq.com/faq/can_one_pr..._process_table, http://www.jlcomp.demon.co.uk/faq/hide_password.html, http://www.dbforums.com/oracle/16163...le-server.html.

My interpretation of the question, based on the title and the content of the post, was that the OP wanted to hide the specific data that is entered on the command-line from the ps command that revealed it.

Therefore I still consider my first comment as fully valid. I understand that this is about leaking passwords.

I also made very clear that modifying the ps command in some way (I mentioned script but it could be a rewriting of the command as well) will not help against a dedicated person as the data is still available.

This topic has been discussed many times on many forums.

Here is a pointer to several ways of hiding the username and password http://www.jlcomp.demon.co.uk/faq/hide_password.html

You may experience reading / echoing problems. I already posted something along the lines of that including the URI you posted.

That's a good point -- MAC / RBAC can solve this problem properly on Linux systems.

I need to take a few weekends to really learn selinux, and write a targeted policy for ps(1). (I think grsecurity is very slick, but AFAIK it's not an option in my case -- RHEL with support.)

Awesome goal. When you get there please consider a write-up for LQ? I'd venture though Fedora, considering the improvements Dan Walsh provides, may present a way easier (malleable) platform to fiddle with compared to RHEL(-alikes)...

Absolutely. This will be a good use of time (assuming I can put together something respectable).

[quote]That's a good point -- MAC / RBAC can solve this problem properly on Linux systems.
I need to take a few weekends to really learn selinux, and write a targeted policy for ps(1).[quote]

Humm, I think you may have a hard time doing that. Currently Fedora, Redhat and others use type
targeted policy i.e. every subject and object runs in unconfined_t domain except for those with a
define policy.

@fpmuphy: Yeah, that appears to be true. (For example, my Fedora 11 system was "targeted" after a default install.)

I haven't researched this enough yet to know how feasible it will / will not be.

-------

edit: I'd add that I don't know or understand selinux well. (If I didn't make that clear earlier in the thread, I will now.)

Next, I get a book, read, understand, evaluate the problem again, make a decision about how/whether it can be implemented, etc.

Unfortunately, I haven't made time to look into this properly yet. I did get a Fedora 12 Beta release announcement email today, and this caught my attention:
That may be promising (or it may be a dead end, since AFAIK ps(1) requires access to the /proc pseudo-filesystem). In any event, something new to tinker with to try to address this problem.

Yes, he has been tinkering with that since his "X guest" posts. The release speed of SELinux features in Fedora is one of the things it has over RHEL and derivatives.