Ownership of /sbin/rc.utils

[mgsa]

Hi All,

Need a pointer to what the ownership should be of /sbin/rc.utils. It's been as a security issue that it's currently owned by bin:sys and should be root:root.

Does anyone know what the default is in a new install and if there any implications to making it root:root ?

Many thanks,

Mike

[SoorajCleris]

Hi,

If you think that the permsission is wrong you may check with swverify. That will give if there any variation from default.

But let me checki in my server.

May I know whcih is your OS version?

Regards,
Sooraj

[mgsa]

Thanks for your prompt reply.

OS rev is 11.*

I believe bin:sys will be default but we are recommended to change it to root:root, am wondering if this will break anything or not.

Thanks!

[SoorajCleris]

Hi,

# uname -a
HP-UX rx260-17 B.11.23 U ia64 3250938661 unlimited-user license
[rx260-17]/sbin
# ls -l rc.utils
-r--r--r-- 1 bin sys 21921 Aug 26 2004 rc.utils
[rx260-17]/sbin
#


Regards,
Sooraj

[mgsa]

Thanks, do you know if it is normal practice to change the ownership to root:root to secure a box?

[James R. Ferguson]

Hi Mike:

> Need a pointer to what the ownership should be of /sbin/rc.utils. It's been as a security issue that it's currently owned by bin:sys and should be root:root.

Sorry, there is no security issue when the ownership is correctly bin:sys. No doubt this is someone's audit who doesn't understand Unix.

Neither 'bin' nor 'sys' are configured to be able to login. You will see an asterisk ('*') in the password field of '/etc/passwd' or '/etc/shadow' for these accounts that prohibits login.

Regards!

...JRF...

[SoorajCleris]

Hi,

I dont know why it is recommended. And the system defualt permission will be as per the requirement of the sytem and most secured.

I don't support this change !!!

Regards,
Sooraj

[mgsa]

Thanks guys, that's what I needed.

[Bill Hassell]

I will never follow an auditor's recommendation to change the manufacturer's (HP) settings. These have been in place for many years and unless the auditor can point to an acknowledged security vulnerability, "improving" HP-UX security is an easy way to cause all the syadmins a *lot* of extra work trying to fix things. The auditor leaves and you have to fix the damage. The bin and sys logins are never enabled so it is unclear why there is even a concern. As mentioned, the auditor is likely unfamiliar with HP-UX.

NOTE: Not everything on an HP-UX system is controlled by HP. You may add databases, new users, new directories, etc. You want best practices for secure syadmin tasks and avoid 666 and 777 like the plague.