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?
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.
Then you will end for users to see the main home directory like:
.
.
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...
You could install a shadow file or go "trusted"...
If I remember right all spooladm directories are group bin yes?
What do the other users do ( even though menu driven...) on the box? what user application is run?
The only openspool I have hands on is on an old Bull AIX4.2 and I'm sure it is BULL custom (OPENPAGE software)
And this box has only me defined except root and spooladm...
$ who -uA
spooladm lft0 Aug 29 07:20 old 5524
spooladm pts/0 Aug 29 07:20 old 32054 (:0.0)
spooladm pts/3 Aug 29 07:20 3:47 31538 (:0.0)
spooladm pts/2 Aug 29 07:20 . 31796 (:0.0)
spooladm pts/6 Aug 29 07:20 old 32312 (:0.0)
spooladm pts/4 Aug 29 07:20 old 32570 (:0.0)
spooladm pts/5 Aug 29 07:20 old 32828 (:0.0)
spooladm pts/1 Aug 29 07:20 old 33086 (:0.0)
spooladm pts/7 Aug 29 07:20 . 33344 (:0.0)
vbe pts/8 Mar 5 17:00 . 79530 (ant)
.
.
I tried that, worked fine, helped me reach my objective, but then we realized that our backup solution, Symantec's BackupExec and its RALUS agent for Unix stopped working, as it is not compatible with HP-UX trusted mode.... It is a known issue at Symantec, and they even don't have plans to correct that.
So I'm stuck with an obsolete product (OpenSpool) that will follow best practices in security, but don't accept my workaround, and on the other hand current software that does not adhere to security best practices...
From your suggestion, I installed ShadowPassword bundle, which seems to be a subset of the trusted system, because it removes encrypted passwords from the /etc/passwd file and puts them in /etc/shadow, which is only readable by root.
Man this fits my need 100%, BackupExec still works, and malicious users can't make good use of /etc/passwd (ex John the Ripper).
I cheered to fast, The BackupExec console will not connect to the RALUS agent on /etc/shadow - enabled HP-UX 11.11 server...
Back to the drawing board...
I read in other forums that older builds of the BE agent, namely version 10, will work in such an environment, I'm currently trying to get a copy of that agent version.
I know that this is going backward, and not looking good for the future, but this is a current need that we want to address. Once solved, we can take better decisions for future development of our backup infrastructure...
Isnt there a parameter you set in the config file of BackupExec where you specify where the file wich contain the passwd? ( case for su2 but doesnt work...)
the truth is I cant believe you cant het it working on HP when now you are solaris compliant (for passwd) and that is supported...