I have inherited some software that is running on HP-HX 11.11. The software ofers a GUI login and the user passwords can be either internal to the software, user defined or based on the matching unix account. The problem I have is that the server has been converted to 'trusted' years before I got hands on. The software, of course, only looks in /etc/passwd and is so old that fixes are no longer written. :rolleyes:
The software had a total collapse on 01/01/2012 because of a design flaw. There is the capability to set a user end date, and the logic failed similarly to the worries everyone had about year 2000. Having never dealt with it before, I soon discovered that no user accounts had a password at all and account sharing was very common. So, I crashed headlong into setting up something, at least. We've caught quite a few offenders already now that services are resumed;) and I have an lsof based script trace written to react to each login attempt.
Unfortunately the internal password controls allow a single character password (including space) and no history is kept.:wall: We do set more sensible rules for OS telnet users, but I cannot tie the software in without converting back from TCB.
Finally, my questions:-
How? Is it just a sam action?
What do I lose?
What do I risk?
I've trawled the archives, but nothing leaps out. Perhaps it is an odd requirement, but any guidance would be appreciated.
Many thanks, in advance,
Robin
Liverpool/Blackburn
UK
Thanks for the input. A regular DR backup is in place and tested over the past few years. Back it up before you <insert expletive here> it up is a very good rule, especially with something a bit serious like this.
Unfortunately I cannot find anything about /etc/tsconvert. Trying to execute with a -? flag I just get "Not Superuser" and I dare not run it as such just yet. :o
I am interested in what the differences in control and risks are between the two. There must be a reason for converting to Trusted State in the first place.
Trusted systems with bastille are in most cases part of DMZ and are that kind of systems to conform various security standards like PCI-DSS.
Read about trusted system online, there is alot of coverage there with examples and detail explanation what it does.
I cannot advise you further since i have made this once on HP virtual machine.
If you have doubts, do a backup of entire system, that's the safest way.
Be aware that on trusted systems, it will ask you to give the old passwd for all account even root's when you want to change it...
Some software ( even old ones...) are "trusted aware" and you risk to find yourself in the same situation: I am talking of installing the shadow package/patch... Some software not finding passwds in /etc/passwd look for the trusted database which doesn't exist if you are using shadow file... I had the case with HP su2 utility that compiled without any errors but was not working... and some issues with Reflection products...
The good news is that the root password is not known and not required except in an emergency, so would only be on the console anyway (frequently changed by Security and stored in a file on another server). Administrative updates requiring super-user privilieges are scripted with sudo rules - and the system managers (of which I am one of five) have the wonderful ability to sudo su - to do anything that isn't 'normal'
I'm still not sure what being 'trusted' gives me. It just was already 'trusted' when I got given the opportunity to take it on (i.e. dumped with it) Does untrusted just mean that the passwords are stored (encrypted) in /etc/passwd field 2 so there is a risk that someone might peek and then decipher them? Will I lose the complexity/history rules for passwords or something else perhaps? I will be delighted if it doesn't re-prompt for the old password when I've just typed it in, and as for that generating a next password malarky, no thanks. All users, be they IT or not, hate it too.
We're not public facing, so I'm not too worried about intrusion (dare I trust my network team?) but if my Security Manager will kill me for even suggesting it, it would be good to know what we're actually giving up, given that I'm trying to improve security on an application for him, after all.
To read about "untrused", just see "man passwd". You will lose complexity and history rules. The "root" user will not need to know an old password. Passwords will be stored encrypted in /etc/passwd, but there is no direct unencryption method beyond brute force by a "root" user.
Keep some sessions logged in as "root" if you make this change. I recall that all existing user passwords were lost during the change from "trusted" to "untrusted" and that every user needed a password reset. Don't know if this has been fixed. HP Openview stopped working and need a re-install.
The "sudo" command is not a HP-UX command. It is 3rd-party software which administrators elect to use in order to bypass "trusted" security. No guarantee that it would continue to work unchanged.
I can't see how changing from "trusted" to "untrusted" will fix your application problem.
As others advise, make a full Disaster Recovery backup before considering this change.
There is the capability to set a user end date, and the logic failed similarly to the worries everyone had about year 2000. Having never dealt with it before, I soon discovered that no user accounts had a password at all and account sharing was very common. 
