Running listener as nobody

[Tim Medford]

The results of an external audit said that we are exposed becuase we run the listener as oracle. We should be running it as "nobody" instead.

Has anyone ever tried to do that? I can't figure out how to set it up. Doing an su - nobody -c "lsnrctl start" does not work. Maybe it's just a matter of changing ownership of the listener binaries?

I'd appreciate any ideas you have?

Thanks, Tim

[Christopher Caldwell]

Do you really have the user "nobody" on your system (i.e. grep nobody /etc/passwd).

What happens when you
$su - nobody?

If you've got a nobody account, what doesn't nobody's environment look like? (e.g. as the use nobody, post the results of
$ set

[Tim Medford]

The nobody account does exist in /etc/passwd:

nobody:*:-2:-2::/:

When I attempt an su - nobody it says:

su: Invalid ID

[Jeff Schussele]

Hi Tim,

You can't log directly to nobody.
It's generally used for anonymous connections - mainly NFS.

I doubt that even IF you could make that work, you would really want to.

Sounds like another auditor whose had just a teeny bit too much caffeine, if you ask me.

Ask the auditor just *why* one would want to do that & that you'd like a reference to another client who has done this. I'd be curious to hear that answer.....

Yes, we all know that there are a zillion Oracle exploits out there, but I seriously doubt to whom the listener process belongs plays a part in any of them.

My 2 cents,
Jeff

[Michael Steele_2]

I've seen this with NFS where the account ???nobody??? is substituted for root ownership and it will work.

This link seems to indicate that you have to change the UID and GID before using ???nobody???.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x4e76402f24d5d61190050090279cd0f9,00.html

[Christopher Caldwell · Accepted solution]

The concept of "nobody" from a security standpoint comes from the premise that a particular user owns no files in the filesystem, hence the user can do no damage if the user's account (or the application -- the listener) gets compromised.

On HP-UX, the user nobody is reserved for NFS:

$ man 4 passwd
The uid of -2 is reserved for remote root access by means of NFS. The
pw_name usually given to this uid is nobody. Since uids are stored as
signed values, the following define is included in to match
the user nobody.


The attributes of "good" nobody accounts are as follows:

unique username and id
no shell
user owns no files

Apps that are "nobody" aware (e.g. httpd) have easy ways to reference such accounts. The su - isn't required, you simply tell the daemon to run as the un-priv'd user after initial startup.

You won't be so lucky with tnslsnr. The "user" for tnslsnr will need an environment that has ORACLE_HOME and ORACLE_BASE defined, and it'll probably need a pointer to the oracle library files (SHLIB_PATH)-- so you'll need a home directory and a .profile. Further, if you use su -, you'll need a shell.

You'll still see some benefit, for presumably the user will own _few_ files in the file system.

Pick a name that means something to you (like tnsuser) and a uid that you'll remember and easily ID(like 59999). [Don't use nobody on HP-UX].

[Yogeeraj_1]

hi tim,

just a few clarification:

This is a common requirement for users who run "extprocs" (external procedures)
in oracle8.0 and up for example. Since an extproc runs as the userid who
started the listener, it is common to setup a listener that runs as the user
'nobody' or some other low priv'ed account to spawn the extprocs. A 'regular'
listener listens for all other inbound requests.

hope this helps!

Best Regards
Yogeeraj

[U.SivaKumar_2]

Hi,

The problem is the negative IDs used.

edit /etc/passwd
Confirm UID 99, GID 99 is not used by any user.If it is used then select a unique ID for UID and GID. Then use it in the below steps.

Change this line
nobody:*:-2:-2::/:

To this line
nobody:*:99:99::/:

Edit /etc/group and change the GID of nobody group to 99.

Ensure that the PATH variables are set for Oracle directories in .profile of root. The permissions of root's .profile should read-write for root and readonly for group and others.

Now as root go the oracle bin directory where lsnrctl binaries resides.
#chown nobody:nobody lsnrctl
#chmod 500 lsnrctl

Now

#su - nobody -c "lsnrctl start"

#ps -ef | grep lsnrctl

It should run now.

If there is any PATH problem you can use this format specfying full path of lsnrctl binary.

#su - nobody -c "/myapp/oracle8.x.x/app/bin/lsnrstl start"

regards,

U.SivaKumar

[Steven E. Protter]

Let me be blunt and apologize for my language.

That is absolute bullshit.

I question your auditors competance at this point.

So long as oracle is in its own group and the umask is 022 when installed, there are no known security hazards from running oracle or its listener as oracle.

None.

Check yourself at metalink.oracle.com

I talked to an Oracle tech and searched their system, there is no security hazard from running the listener that way.

If there was a security hazard, oracle would have issued a patch.

All you need to do is keep up with Oracle security patches and you're fine.

As far as actually solving the problem, changing permissoins will probably work.

Just one thing. If Oracle finds out you did that they'll tell you the configuration is unsupported.


SEP

[U.SivaKumar_2]

Steven ,

I strongly disgaree with your opinion

If you run Oracle listener as oracle. Then Anybody can workout a buffer overflow exploit against the oracle listener. And write his own malicious code in the memory which will be executed as user oracle . This malicious code can delete , control all your databases as the effective user of the running arbitrary code is oracle. This vulnerability is already released.

Is this not a security threat ??

Oracle has fixed this potential security vulnerability in the Oracle9i database server. Oracle is in the process of backporting the fix to supported Oracle8i database server Releases 8.1.7 and 8.1.6 and Oracle8 Release 8.0.6 on all platforms.

I do agree that patching is best solution if the nessecary patches are available for necessary versions.

Many unix applications are recommended and have inherent support to run as different dummy user ONLY FOR THE SAKE OF SECURITY. For example named , httpd , sendmail , squid etc.

So your criticism of the above method opted by Author is simply Improper.

In a nutshell , Never underestimate the words of a Security Consultant nor the work of a Hacker :-).

regards,

U.SivaKumar