jueves, 13 de noviembre de 2003

Enhanced Security en tru64

From: Jon Buchanan <Jonathan.Buchanan@ska.com>

You asked for the pros and cons of Enhanced Security. Well, here's my view:

Pros:

+ a protected password database
+ records last successful and unsuccessful logins
+ records repeated login failures
+ automatic lockout after repeated login failure
+ configurable minimum password length
+ password lifetimes
+ password quality checks
+ password change history
+ password usage history
+ GUI for user account maintenance
+ templates for user setup
+ audit subsystem (means C2 security requirements can be satisfied)

Cons:

- performance problems with very large user base (>1000 users)
- NIS doesn't work with other operating systems
- still not as secure as Sun's NIS+
- no (official) failover for NIS master -> single point of failure
- new and not very well understood, even by Digital!

To answer your questions:

1) Turn enhanced security on/off with the secsetup utility. However, if
turning it off, you may find that you need to give all users a new password.

2) Follow the procedures in the 'Security' manual to migrate users from base
to enhanced security. They provide scripts which do it for you.

I think you should decide first whether you want Enhanced Security or not,
and then deal with the admin problems that arise. However, don't base your
decision on the admin problems, base it on your need for security.

Attached is a general list of tips and notes regarding Enhanced Security.
It provides detail on some of the issues just mentioned.

Regards,
Jon Buchanan, Zuerich, Switzerland
[ Jonathan.Buchanan@ska.com ]

Some tips and notes about Enhanced Security:

With enhanced security, your user, group and password databases are
divided into many places:

/etc/passwd
This contains entries for local users not defined under NIS.
Passwords are not stored here - a * appears in place of each password.
Typically you would leave the system users like root, deamon etc here.
NIS-defined users must not appear in this file!
At the end of this file is +: for NIS to be searched.

/tcb/files/auth directories
Users defined in /etc/passwd have security profiles in these
directories. Their passwords, and things like successful/unsuccessful
login info are stored here. No NIS users have profiles in these
directories.

/etc/group
This contains entries for local groups not defined under NIS.
At the end of this file is +:

/var/yp/src/passwd
This is your NIS passwd file.
Local users, defined in /etc/passwd, should NOT appear here!
Passwords are not stored here - a * appears in place of each password.
The file should not contain +:

/var/yp/src/prpasswd
This is the 'protected password' NIS file, which functions like the
/tcb directory but for NIS users instead of local users. All users
with an entry in the NIS password file have an entry here.

/var/yp/src/group
This is the NIS group file.
Local groups, defined in /etc/group, should NOT appear here!
The file should not contain +:

Creating the prpasswd file is described in the section 'Moving Local
Accounts to NIS' in the 'Security' manual. You have to copy the script
they give you in the book, which reads all the information from the /tcb
tree and writes it into a file with one line per user. After that you
need to:

- delete (or move) all security profiles below /tcb for NIS registered
users
- delete all prpasswd entries for locally registered users (like root)

this is in accordance with the split described above.

When you are using the advanced security XIsso and XSysAdmin tools you
choose whether to manage the local or NIS registered users by clicking
on the 'Network Control' button. It then updates only the appropriate
files, and in the case of the NIS files, does a make for you.

To change passwords, use passwd for all accounts including the NIS ones.

/etc/svc.conf should contain an entry like: auth=local,yp

Delete the files /etc/passwd.dir and passwd.pag if you have them. These
are 'hashed' password files which adduser offers to make for you when it
finds they are not there. However, you don't need them and it will
probably stop NIS from working properly.

The main problem with switching Enhanced Security/NIS on and off is in
restoring the information to the correct place. Above all, Enhanced
Security passwords CANNOT be re-inserted into the passwd files (in place
of the *'s) - you need to give all users a new password.

A couple of problems that took us a long time to solve:

- The file /etc/auth/system/files must contain entries for
prpasswd and prpasswd:t. We have added them like this:

/var/yp/src/prpasswd:\
:f_type=r:f_mode#0660:f_owner=auth:f_group=auth:\
:chkent:
/var/yp/src/prpasswd\:t:\
:f_type=r:f_mode#0660:f_owner=auth:f_group=auth:\
:chkent:

- An Enhanced Security NIS Slave cannot operate independently of the
Enhanced Security NIS Master. This is because the prpasswd file
is updated with every login attempt, and is only mastered on the
NIS Master. In other words, there's no point having a Slave because
it won't be able to function without the Master running.

DEC have refused to acknowledge this as a problem, so a fix is
unlikely for the forseeable future. We have worked around it by
setting up a second Master and copying certain files from the
'real' master to the 'second' master periodically using rdist.
It is not an altogether satisfactory solution but it works and we
prefer it to being dependent on the availability of one machine.
Let me know if you would like more details on setting this up.

If you are determined to set up a Slave then you may hit another problem
too, whereby a make of the yp maps pauses for a few minutes. Fix is to
send the Slave the copies of the maps which it is missing by using ypxfr
(but a better fix is to disable the Slave).

One other note about Enhanced Security - if your system manages X
sessions for X displays (such as PCs) then you will need to add entries
for these remote displays to the files /etc/auth/system/devassign and
/etc/auth/system/ttys. I can let you have more details if you need
them.

From: Spider Boardman <spider@Orb.Nashua.NH.US>

I'm afraid your question didn't make a lot of sense to me, unless
I assume that you don't have Enhanced Security in use, but that
you merely have its subsets installed (which is not enough to
enable it).

In particular, check the output of running this command:
/usr/sbin/rcmgr get SECURITY BASE
If it's BASE then you've not enabled Enhanced Security.

The /usr/sbin/secsetup script is supposed to take care of
creating prpasswd entries (the /tcb/files/auth/?/* files) for the
users which were already in /etc/passwd when you enable the "C2"
login features. If it didn't, then that's a bug. I do seem to
recall that the adduser script had a bad habit of creating
prpasswd entrries even when it shouldn't, because it didn't check
the result of the rcmgr command above. Unless that returns
ENHANCED you're still using "BASE" security.