tduncan@secola.Columbia.NCR.COM (Terry Duncan) (04/04/91)
I have recently installed SCO (with relaxed security). I am trying to create a user with superuser privilages. Is this possible? I am also trying to delete a user (retire is not what I had in mind). Is this possible? Where is this "Protected Password Data Base"? I think SCO took this security thing a little too far.
macleod@cmllab.rgb.sub.org (Connor MacLeod) (04/09/91)
In article <328@secola.Columbia.NCR.COM> tduncan@secola.Columbia.NCR.COM (Terry S. Duncan) wrote: | I have recently installed SCO (with relaxed security). I am trying | to create a user with superuser privilages. Is this possible? I am also | trying to delete a user (retire is not what I had in mind). Is this possible? | Where is this "Protected Password Data Base"? Yep - yep - ... It's possible for both - a relaxed _and_ a C2 trusted system. There are four locations where changes have to be made to get a second superuser or delete an user: the first two are: (guess) /etc/passwd and /etc/group (and now for the interesting stuff) the 3rd place you have to check is the path /tcb/files/auth. You'll find 26 subdirs there (/tcb/files/auth/a to /tcb/files/auth/z). You have to check the directory which is similar to the first char of the users name (root => .../r). You'll find a file for each user whose name starts with the char of the subdir. All the files here are in charge for the environment of each user. The 4th place is /etc/auth/subsystems. The files there are in charge for the privs of each user. So... Let's say you want to create a user called foobar with superuser privs: use the sysadmsh (or useshell) to create a standard user called foobar. Then edit /etc/passwd and /etc/group and change the entry for foobar to match the one from root. After that chdir to /tcb/files/auth/f and ed the file foobar. Remove all _after_ the ":u_pwd=........" line and append all from file /tcb/files/auth/r/root but not the first two lines. Chdir to /etc/auth/subsystem and check all the files there. Every file that has an entry for root must have the same entry for foobar, too. Remove the foobar entry from dflt_users. That's it. To remove an user from the system do the following steps: - remove the users entries from /etc/passwd and /etc/group - remove the users entries from all files under /etc/auth/subsystems - remove the file with the same name as the username from the appropriate subdir under /tcb/files/auth - remove the users homedir and mailbox (not necessary) | I think SCO took this security thing a little too far. It's C2 Trusted... (not SCO - anyway) BTW: the SLS unx257 has some usefull tools (shell-scripts, I think) which does this work for you. After having installed this fix you'll get some warnings when booting in case you have more than one user with superuser privs. I think you can ignore them... (I hope so - at least :>) I hope this is of some help... Rgds -- Uwe Obst # {connor|macleod}@cmllab.rgb.sub.org (aka Connor MacLeod) # "Trust me, I know what I'm doing!" -- Sledge Hammer
paulz@sco.COM (W. Paul Zola) (04/12/91)
In article <328@secola.Columbia.NCR.COM> tduncan@secola.Columbia.NCR.COM (Terry S. Duncan) writes: } } I have recently installed SCO (with relaxed security). I am trying }to create a user with superuser privilages. Is this possible? I am also }trying to delete a user (retire is not what I had in mind). Is this possible? }Where is this "Protected Password Data Base"? } } I think SCO took this security thing a little too far. The following articles from the SCO Information Tools database should help with your problems. Sorry about the length, but I think this may be of general interest. ################## cut here ################ cut here ################## How to remove a user on SCO UNIX System V/386? KEYWORDS: unix remove existence user custom c2 password tcb group unx257 rmuser RELEASE: SCO UNIX System V/386 Operating System Generic Open Desktop Generic PROBLEM: How do I remove a user from SCO UNIX System V/386? SOLUTION: Install Support Level Supplement (SLS) unx257. This SLS provides the rmuser(ADM) utility which will allow you to completely remove a user from the system. SEE ALSO: The item in this databse describing SLS unx257. ################## cut here ################ cut here ################## I want to use either the C or Korn shell as root. KEYWORDS: root csh ksh korn shell .login /etc/passwd password database bad hz hertz value unix RELEASE: SCO UNIX System V/386 Operating System Generic Open Desktop Generic PROBLEM: How do I set up a root csh or ksh account under SCO UNIX System V/386 or Open Desktop? I want to use either the "C" or Korn shell as root. CAUSE: By default, the "root" login uses the standard Bourne shell, /bin/sh. This is in fact necessary for correct system operation; the default shell of the "root" login must not be changed. Changing it can lead to mysterious "Bad Hertz Value" messages from programs such as df(C) and mount(C) and may have more serious consequences. SOLUTION: It is not difficult to create an alternate root login that uses the shell of your choice. It is necessary to use a user name other than "root" because some components of the system require the "root" login to use the Bourne shell. The steps to create a C or Korn shell root login are simple, but it is recommended that you perform them after a complete system backup, in case anything goes wrong. In the example, accounts named "rootcsh" and "rootksh" will be created. Note that it is your responsibility to set up the login environment using .cshrc or .kshrc files; no such files will be created automatically. When setting up the Korn shell, be sure not to make changes to /.profile which would markedly change the environment of "root". The steps involve directly editing /etc/passwd and the protected password database. Because of this, they MUST be performed from System Maintenance (single-user) mode. Before beginning, shut down the system with shutdown(ADM); reboot and enter the root password to enter System Maintenance Mode. First, new protected password database entries must be created for the new accounts. Start by copying root's entry: # cd /tcb/files/auth # cp r/root r/rootcsh # cp r/root r/rootksh If you want to use different user name(s), be sure to create the files in the correct subdirectory of /tcb/files/auth, corresponding to the first letter of the chosen user name. Now edit the new entries as follows: Find each occurrence of the name "root" and replace it with the new name, EXCEPT the item "u_type=root". "u_type=root" does not refer to the user name and must remain the same. Use vi(C) or the editor of your choice. Do NOT use a word processor that uses special characters for formatting. Be very careful not to change the format of the files in any way; change only the name entries. If the format of these protected password files, or of /etc/passwd is damaged, you may not be able to log into the system at all. The default /tcb/files/auth/r/root file looks like this (Note: lines marked with '*' were split in order to fit on the page): root:u_name=root:u_id#0:\ * :u_type=root:u_owner=root:u_cmdpriv=audit,auth,backup, cron,lp,mem,sysadmin,terminal,uucp:\ * :u_syspriv=configaudit,writeaudit,execsuid,nopromain, chmodsugid,chown:\ :u_minchg#0:u_exp#0:u_life#0:\ :u_pswduser=root:u_pickpw:u_genpwd:u_restrict@:u_nullpwd@:\ :u_maxtries#0:u_lock@:chkent: An equivalent entry for a rootcsh account looks like this (in /tcb/files/auth/r/rootcsh): rootcsh:u_name=rootcsh:u_id#0:\ * :u_type=root:u_owner=rootcsh:u_cmdpriv=audit,auth,backup, cron,lp,mem,sysadmin,terminal,uucp:\ * :u_syspriv=configaudit,writeaudit,execsuid,nopromain, chmodsugid,chown:\ :u_minchg#0:u_exp#0:u_life#0:\ * :u_pswduser=rootcsh:u_pickpw:u_genpwd:u_restrict@: u_nullpwd@:\ :u_maxtries#0:u_lock@:chkent: Next you need to edit /etc/passwd. Find the "root" entry and make a copy of it for each new account. Carefully change the user name of each entry from "root" to the new name. Then change the shell field to the desired shell. This is the last field of the record; it should currently either be blank or read "/bin/sh". If it is blank, append "/bin/csh" or "/bin/ksh" AFTER the last colon (:) on the line. If it reads "/bin/sh", just add the necessary "c" or "k". (Note that the Korn shell is not available under SCO UNIX System V/386 Release 3.2 or Open Desktop Release 1.0.0). The default /etc/passwd entry for "root" looks like this: root:*:0:1:Superuser:/: After editing /etc/passwd, the "root" entry should be the same. However, a new entry, such as the one that follows, should be present: root:*:0:1:Superuser:/: rootksh:*:0:1:Superuser account with Korn shell:/:/bin/ksh Remove the user and group map files; they will be re-created when the system is rebooted: # rm /etc/auth/system/pw_id_map /etc/auth/system/gr_id_map Finally, run sysadmsh(ADM). Select Accounts -> User -> Examine and enter the name of the new account. Choose "Privileges". You must make a trivial change to the privileges and save them, in order to activate the changes made in the protected password database. It is sufficient to add "lp" to the end of the Subsystem list. Even though "lp" is already in the list, sysadmsh will be fooled into believing you have made a change. It will then ask if you wish to have the modification take effect. Enter yes. Now choose "Identity". Move to the Groups list and enter all the groups in which "root" is a member. (You may use sysadmsh to examine the "root" account, or you may use the command "grep root /etc/group".) You can now reboot the system and log in as "rootcsh", "rootksh" or whatever account you have created. Remember, as always, to be very careful when you are running with root privileges and to do so only when it is necessary for system maintenance tasks. NOTE: Be aware that the passwords for the different "root" accounts will be distinct. They will start out the same because the new accounts' protected password entries will have been duplicated from "root". But when you change root's password as part of your regular security measures, be sure to change the other accounts' passwords as well. It is probably safest to use the same password for all root accounts since breaking into any one of them completely compromises system security; there is no point in having several different strings which a potential troublemaker might be able to guess. ################## cut here ################ cut here ################## I hope this helps you with your problem. - Paul Zola Software Support Engineer paulz@sco.COM Gotta tend the earth if you want a rose. - Emily Saliers DISCLAIMER: I speak for myself, and not for SCO.