HP-UX

My goal is to protect the /etc/passwd from unauthorized viewing. I wish ti change the permissions of the file to :

-r--r----- 1 root bin

so only root or accounts of the "bin" group could query this sensitive file. All our other processes have been ajusted to not need any info from /etc/passwd.

The spooladm user has "bin" as its primary group, and is running all the OpenSpool processes.

When I changed the permissions, the Openspool's "np" program called by regular users stopped working immediately, returning the error:

No OpenSpool realm default language is set, proceeding with C.
INTERNAL ERROR: get_path returns error.

If I run the "np" command under root, the commands executes successfully. I conclude that the process, under a regular user's context, can't read the /etc/passwd file.

I can't figure out how a workaround for that, because I don't know if it is the "np" command itself, or if it is from a forked sub-command.

Maybe there is a tweak in OpenSpool, anybody has an idea?

I really want to have those permissions set.

I'm wondering myself on what's been done for protection.

Well Martin,

Do you see a comment on spooladm user in /etc/passwd?

If yes,

Un-comment it, shutdown the spooler and restart it.

-DB

No, the user is not uncommented, in fact we use it to run npui, the OpenSpool management interface. Also, all spooler processes (queues and brokers) are ran under spooladm.

Because the user spooladm has access to the /etc/passwd file (because of "r--" bin group permission, we can use the "np" command successfully while logged under the spooladm account...

Other users that don't belong to the "bin" group can't print because they are obviously denied access the the /etc/passwd file. Why in the world the "np" process need access to that file ? My guess is it looks for the home directory of "spoolam", or the UID number. If there were an alternate way to provide this information (environment variable, or setting in Openspool or a config file), then I would be saved...!

I even tried to change permissions to 4555 on "np" (set sticky bit) so that the program would be run under the owner's (spooladm) context.

Does not work....

Then you will end for users to see the main home directory like:

Code:

.
.
drwxr-xr-x   2 2070       users         1024 Dec 20  2004 bus
drwxr-xr-x   2 2066       users         1024 Mar  7  2005 calo
drwxr-xr-x   2 2017       users         2048 Jan 19 12:32 card
drwxr-xr-x   2 2018       users         2048 Oct 28 16:42 care
drwxr-xr-x   2 2005       users         1024 Jan 16  2006 carv
drwxr-xr-x   2 2019       users         1024 Mar  2 14:55 cas
drwxr-xr-x   2 2020       users         1024 Mar  4 16:31 cav
.
.

So anyone can guess the UID...
But then unless you are also in group bin, how will you identify alien files (true users files vs ftp or deleted account orphan files etc...)
And program which read /etc/passwd to see if you are entitled to changes in profile or env (usually in /etc/profile or ~user/.profile) will also fail...( you know like oracles "am I a DBA?")

I understand, you think that is is a bad idea to not grant read authority to /etc/passwd. In fact, regular users are greeted with a menu of our application, they don't have access to the prompt.

Also, we don't have any program that rely on /etc/passwd entries anymore, I have ajusted in-house scripts accordingly. Everything runs fine but that stupid OpenSpool, which we can't get rid of at the moment.

I'm just trying to make the server safer to prevent stealing of the /etc/passwd file by a hacker.

So this thread is really specifically aimed at finding a solution for the "np" command being able to read the /etc/passwd without effiective permissions, or a workaround for getting the same information it is looking for.

I'm trying to get help from a OpenSpool guru, or a wise guy that faced the same challenge...

Thanks for the input, though.

What model? (PA/itanium?) what OS version?

server is PA-RISC, RP series, running HP-UX 11i. (11.11)

OpenSpool is B.01.60