Trusted system vs Non trusted system

[Ngoh Chean Siung]

Hi,

What is the difference between trusted system & non trusted system? Any reasons to use trusted system? Is there any acticle or documentation about it?

regards

[Bharat Katkar · Accepted solution]

Hi,
See the doc attached about how to set up the Trusted System. You will get know the advantages as well.
Regards,

[Geoff Wild]

This online doc also has information on setting up a Trusted System:

http://docs.hp.com/hpux/onlinedocs/5187-2216/5187-2216.html

Rgds...Geoff

[Patrick Wallek]

The basic difference is:

Non-trusted - encrypted passwords are stored in the /etc/passwd file, which is world-readable. Potentially anyone could grab that file and run crack or some other password cracking utility against it.

Trusted - encrypted passwords are NOT stored in /etc/passwd. They are instead stored in files in the /tcb/files/auth/ directory structure which is only readable by root.

Other advantages are that you have more control over when passwords expire, you can disable accounts after X number of bad logins in a row, etc.

I think it is definitely worth it to have the system be trusted.

[Gary L. Paveza, Jr.]

Just a quick comment. HP has released software called Shadow Passords which removes the encrypted passwd and puts it into a root only /etc/shadow. This is for untrusted systems.

[Muthukumar_5]

Non Trusted systems:
=====================
User informations for the system are stored in the /etc/passwd ( files ) ldap database (ldap) etc. When a user enters into the system,his login and passwd details are verified as identification & authentication method using the encryped passwd in /etc/passwd file.

We can hack the passwd's in the /etc/passwd by removing the passwd for the user in the /etc/passwd file. Are we can use another passwd file for this. or any other respository to store the passwd's as like ldap or nis or nisplus etc.

We can use + or - signs to give access and ignore on NIS type on non-trusted systems.

Users can login without any passwd in non-trusted modes.

Passwd expiration management uses some period of time using min and max. In non-trusted systems,it is rounded to any nearest weeks.

On an untrusted system, only the first eight characters of a password are significant.

passwd changes from old to New passwd can be done with out any restrictions. We can put the same old passwd as new passwd

Trusted systems:
================

User passwd informations are stored in the /tcb/files/auth/*/* (Protected password database used when system is converted to trusted system)

Hacking passwd using the passwd database files are not possible.

we can not use NIS's + or - for giving access to user or ignore them

users cannot use the blank passwd on the trusted mode.

Passwd expiration management uses the corresponding week days for the calculation of min or max periods

we can have passwd upto 40 character length( upto 40 character length is advisable)

passwd changes from old to new is having a restriction as 3 characters must be changed and 1 character for admin users in trusted mode.

Trusted systems are used to secure the systems from passwd database hack and with acl settings.

see the default,passwd man pages to know more.

We can identify the system is trusted or non-trusted using the file /tcb/files/auth/system/default or with iscomsec call.

We can audit the trusted systems log using sam.

Unix basic trusted systems functionality is specified here at,
http://osr5doc.ca.sco.com:457/OSAdminG/ssC.trusted_concepts.html

Regards,
Muthukumar.

[R. Sri Ram Kishore_1]

Hi,

Here's a nice write-up on the same topic:
"1. A trusted system allows system auditing to be turned on.
System auditing enables the ability to trace every system call issued by each user on the system. Non-trusted systems run with system auditing disabled.

2. Trusted systems have improved password management.

Below is a list of password management features:

a. Specification of a grace period and expiration period for passwords.

b. The ability to specify system-wide password aging.

c. The ability to specify an absolute account life.

d. The ability to disable accounts after repeated login failures.

e. Passwords lengths of up to forty (40) characters.

f. The ability to access a random password generator.

3. Trusted systems have additional login restrictions, while non-trusted systems do not. Below are the features of trusted system login restrictions:

a. In addition to account disabling, the account may also be locked.

b. Setting accounts to be accessed only at certain times of the day.

c. The ability to specify account location access. In other words, account access at specific devices, workstations, and so on.

d. The ability to specify a single-user boot password.

Note: These login restrictions are NOT available on NON-TRUSTED systems.

4. A trusted system has shadowed passwords, while a non-trusted system does not have shadowed passwords. Shadowed passwords are kept in locations other an /etc/passwd. This prevents users from viewing /etc/passwd file and determining which accounts do not have passwords. This also prevents hackers from running "password cracker programs" against passwords in the /etc/passwd file.

For more information, please refer to the following document:

"Administering Your HP-UX Trusted System"

The document is located at the following web site:

http://docs.hp.com/hpux/onlinedocs/B2355-90121/B2355-90121.html

Locate the "Description of the HP-UX Trusted System" section in
the left menu. The following two pages contain more information:

o What is a Trusted System?

o What is C2-Level Trusted Mode?"

Source: http://www.faqs.org/faqs/hp/hpux-faq/section-68.html

HTH.

Regards,
Sri Ram

[R. Sri Ram Kishore_1]

Hi,

You might also be interested in these docs:
a) www.giac.org/practical/GSEC/Stephen_Radford_GSEC.pdf

b) wwws.sun.com/software/whitepapers/wp-ts8/ts8-wp.pdf

HTH.

Regards,
Sri Ram

[Colin Topliss]

Don't use it unless you have to AND you have tested it thoroughly.

C2 (Trusted) will break most client-server application authentication as the method used to get password information changes. Instead of using getpwent, the call changes to getprpwent. If the client software does not cater for this then it will stop working.

Also you need to be aware that enabling C2 also enables all sorts of auditing controls. We had a weird problem with cron after enabling C2!

Other issues we saw were to do with things like passwords (though this may have since been addressed). IF the password was not C2 compliant BEFORE the system was converted to C2, the it was not possible to change the password at all. Nor was it possible to log in. Luckily that time round I still had an active root session....

Finally, yes, the shadow password capability is now available as a separate software depot. However, certainly when I last looked at this it did NOT support a number of the name services (NIS and LDAP certainly).

The answer is to test, test, test, then test some more before committing to running your applications on a trusted system.

If you have a development environment, then I'd start there - if your developers are forced to work and develop on a C2 system, then the code they develop will more likely work in a C2 production envieonment.

Col.