SUMMARY: 3.2 and C2 Security

From: Cardell Orrin <corrin_at_mecca.mecca.org>
Date: Tue, 18 Jun 1996 10:50:05 -0500 (CDT)

The original mail was about using Enhanced Security, whether I could turn
it off and on, and what were its pros and cons.

I got back some very helpful answers. I found out that I wasn't in
Enhanced Security, I just had all the files for Enhanced installed. It
seems that the security setup doesn't get rid of the files for Enhanced
Security which can cause a problem for qpopper, and led me to believe I
might be in Enhanced mode. I didn't make that too clear in the first
post, which confused some. But the responses gave me ways to assure
which mode I was in, and gave me the main issues to think about in
deciding whether to use Enhanced or not.

Thanx to:

Spider Boardman <spider_at_Orb.Nashua.NH.US>
Jon Buchanan <Jonathan.Buchanan_at_ska.com>
"Pedro J. Lobo" <pjlobo_at_euitt.upm.es>
Richard Rogers <ittrmr_at_staffs.ac.uk>
Tony Hoffman <ajh_at_digital.com>

Soooo...here are the great answers I got back:

From: Spider Boardman <spider_at_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.

-------------------------------------------------------------------

From: Jon Buchanan <Jonathan.Buchanan_at_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_at_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: "Pedro J. Lobo" <pjlobo_at_euitt.upm.es>

On Mon, 17 Jun 1996, Cardell Orrin wrote:

> 1) Is there anyway to uninstall C2 security. Everytime I add a user

Use 'secsetup' to go back to BASE security.

> now, it puts them into the auth folder. From looking at 'adduser' I
> think I can just delete the auth folder, but I wasn't sure.

You shouldn't use 'adduser' with C2 security enabled. Use XSysAdmin and
XIsso instead. Both are in /usr/tcb/bin.

> 2) On the other side, if I decide to keep the security on (can anybody
> provide pros and cons for this?),

Pros: In a word, it's safer. Passwords are no more stored at /etc/passwd, s=
o
you are not vulnerable to a dictionary attack. Passwords can have more than
8 characters. You can set up expiration dates for passwords and accounts. A=
nd
many more, but I am too lazy ;-)

Cons: Some programs which try to do authentication by themselves won't work=
.
For example, I had to rewrite the authentication code of the pop3 server
I was using, but it is not very difficult.

> do I have to manually remake old
> users who are in the passwd file to add them to the auth directory and
> the protected password database, or is there some script that will do
> that for me??

:-? When you use 'secsetup' to go to ENHANCED security, your user database
is automatically converted. The only thing you must take into account is th=
at
in BASE security only the first 8 characters of the password are used, so i=
f
anyone has a longer password he must type ONLY the first 8 characters the
first time he logs in, and then use passwd to change the password so all
the characters are recorded.

Regards,

=09Pedro.
------------------------------------------------------------

From: Richard Rogers <ittrmr_at_staffs.ac.uk>

On Mon, 17 Jun 1996 16:54:55 -0500 (CDT) Cardell Orrin
<corrin_at_mecca.mecca.org> wrote:

> 1) Is there anyway to uninstall C2 security. Everytime I add a user
> now, it puts them into the auth folder. From looking at 'adduser' I
> think I can just delete the auth folder, but I wasn't sure.

You can use the "secsetup" utility to set the security to C2 or BASE
and back again at will (give or take reboot each time you want to
change over)..
 
> 2) On the other side, if I decide to keep the security on (can anybody
> provide pros and cons for this?), do I have to manually remake old
> users who are in the passwd file to add them to the auth directory and
> the protected password database, or is there some script that will do
> that for me??

The "secsetup" utility takes care of all the movement of password
information as required.

Pros and cons of C2?
For: much better password security (your passwords are no longer
available to just anyone with a copy of crack or similar; long
passwords) and control over the login process (response and limits to
failed logins); auditing information (if you want it).
Against: Any daemons etc that require password authentication will
need to be modified (not too difficult).
Personally, I always use it (well, very nearly always).

Richard

-----------------------------------
Richard Rogers
Information Technology Services
Staffordshire University
Tel: 01785 (+44 1785) 353395
E-mail: R.M.Rogers_at_staffs.ac.uk or ittrmr_at_staffs.ac.uk

-------------------------------------------------------------------


From: <ajh_at_digital.com>

Cardell,

Do not just blow away the auth folder. The passwords are stored in the C2
specific files and nobody will be able to log in if you do.

Run secsetup and say you want to use BASE security. The script will convert
everything back. I'm not sure if it will delete the C2 files. There is an
entry in /etc/rc.config which specifies the security level. That is one way to
check the security level. Also the security manual has some useful information.

Let me know if you have any questions. I am running C2 on a 4.0 system.

Tony Hoffman
Received on Tue Jun 18 1996 - 19:15:44 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:46 NZDT