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

[Christopher Caldwell]

With the "nobody" security model, we're not securing for vulnerabilities we know about, we're securing for vulnerabilities we don't know about. We're saying "assume a network facing application - e.g. httpd or tnslsnr gets compromised -- what can happen?"

The answer is, it depends largely on the privs the "compromised" service has. Compromise something as root, you've got root privs; compromise something as oracle, you've got oracle privs; compromise something as a user who doesn't own anything on the system, you've got the privs to execute world-execute commands.

These compromises are very real. In the compromises I've witnessed, the compromise used the elevated privileges to set up a service (e.g. sh) on another usecured port.

Folks write "scripts" to automatically compromise the system and set up the services (i.e. given that you have the script, you don't have to know what you're doing).

If the user is in as oracle access, minimally, the user can rm the database files.

[Steven E. Protter]

U.SivaKumar,

I respectfully disagree with your opinion. Both concerning the security matter and the appropriateness of my post.

We are current with Oracle server patches, are running Oracle Server with the listener running as the Oracle user.

If Oracle says we should go to user nobody and provides a procedure, we'll do it.

I never underestimate security consultants or the power of hackers. I am carefully following this thread because I don't have the chutzpah to believe that I could not be wrong. I've had two security audits here by large firms. We spent a great deal of time looking at Oracle security, so I don't speak from a position of ignorance. At least not total ignorance :-)

I have a very experienced dba with whom I consulted prior to making my post.

I could be wrong, and will upon reading convincing information admit such.

If I have offended either party, I offer humble apologies.

Tim,Thread author: Please keep the information coming, if you get a valid procedure on this, I'd like to have it, because I'm open minded and inellectually interested. Again if insulted, deepest apologies.

Here is a quote from metalink forums on the subject:

Running Listener as nobody

I am wondering if running the listener as nobody is an option?
By doing so we limit the effects of the Net8 security BOF and others
should they arise.

I am not sure exactly how to do this, but is it deasible ?

-- Donnie





--------------------------------------------------------------------------------

From: Oracle, Kathy Ting 09-Jul-01 22:18
Subject: Re : Running Listener as nobody



No. The Listener can not be run as nobody.

The Listener's ability to receive incoming client connection requests and manage the traffic of these requests to the server will be hinder.






Thank you for using the MetaLink Forum,
Kathy
Oracle Support.

So Am I totally off base here?


SEP

[Steven E. Protter]

I would say based on the response of Oracle support that you should not follow that particular recommendation from the auditors.

I have enough going with Oracle right now and am not going to write a tar to get verification for an itrc thread. That would probably be stretching my oracle support agreement a bit.

I do understand and acknowledge the security concerns that require applications such as squid and apache to be run by users other than the application owner.

Doesn't seem like thats going to work here.

Smiles and happiness and most of all great success.

SEP

[Tim Medford]

Thanks everyone for all the information.

The auditor was quoting some recommendations from a book authored by Dave Litchfield. He also has a web site www.nextgenss.com.

Part of the issue in our environment was that we had not shut off the adminstrative privileges within the listner.ora file (ADMIN_RESTRICTIONS_listener_name=ON). This fact, coupled with the fact that the listener runs as oracle, would allow a hacker to gain control of system with the same autorities as the oracle account. See this document: http://otn.oracle.com/deploy/security/pdf/2002alert40rev1.pdf

Steven - You are correct, I have never seen and cannot find a specific recommendation from Oracle Corp. which suggests running the listener as "nodbody". However there are credible people out there who recommend doing it as a precaution. These recommendations people such as Dave Litchfield and Thomas Kyte. If we had configured the listener.ora correctly to restrict admin privileges this would not have been as big a hole as it was.

At this point I guess it's a judgment call whether to believe Oracle or a number of security consultants.

On a test machine we're going to setup an account similar to nobody but with a proper $PATH and other necessary environment variables and see how well it works with the listener. I will post the results on this thread.

Thanks,
Tim

[Steven E. Protter]

No points please.

I withdraw my comments about your auditors and apologize to everyone who read it.

My conclusion without the stupid emotion was not unreasonable based on the facts at hand. Thanks for the new information, I found the documentation and website very informative.

SEP

[Tim Medford]

No worries Steven! I was looking for a number of opinions and that's exactly what I got.

If you ask me, auditors are in general a pain in the neck. But I guess they do force you to look at things you might otherwise miss.

On the final audit tally, I would say there was at least 1 bogus recommendation for each valid one. The trick is figuring out which ones are which!

Thanks again for the comments and keep them coming. This is what makes the forums work.

Tim