| CONTENTS | |
Unix users are given unique usernames and also added to one or more Unix groups (Section 49.7). Both a user and a group own all content within a system. If you list information about a file, you'll see both user and group ownership:
> ls -l -rw-r--r-- 1 root weblog.burningbi 32230 May 22 13:58 access_log -rw-r----- 1 shelleyp weblog.burningbi 3995 May 12 11:08 analog.cfg -rw-r--r-- 1 root weblog.burningbi 0 May 22 12:01 error_log
In this listing, the users are root and shelleyp, and the group (truncated) is weblog.burningbird.net.
You're assigned a primary group when you're added to a system. In addition, you can also be assigned to one or more secondary groups. Depending on the type of Unix system, you can either work with files that are owned by any one of the groups you belong to or you can work with files of your primary group only.
BSD-based Unix systems allow you to work with files from primary and secondary groups; this includes Darwin as well as the popular PC-based BSD systems, FreeBSD, and OpenBSD. System V systems restrict you to working with a primary group only.
For the majority of Unix systems, user and group membership is controlled through a couple of files, passwd and group, stored in the /etc directory. This directory has root write access only, but read and execute access by all users.
SP
A user is added to the system when they're given an entry in the passwd file, as in the following entry:
mike:*:1007:1007:Mike User:/usr/home/mike:/usr/local/bin/bash
The elements, delimited by colons that make up this record, are:
Name used to login to system
Encrypted password, asterisk symbolizing bad password or use of shadow file, or exclamation point (!) to signify that the password is in /etc/security/passwd or in /etc/master.passwd in FreeBSD systems
Unique user identifier
ID of group that will be primary group for user
General text holding name, address, and so on
In the example, "mike" has a UID of 1007, belongs to group 1007, has a home directory in /usr/home/mike, and logs into a bash shell. In this FreeBSD system, the password is stored in a separate shadow file.
Usernames are usually no more than 8 characters, though this differs based on type of system. Usernames consist of alphanumeric characters and are case-sensitive. Case sensitivity also applies with passwords, which can be longer and use other characters.
The UID must be unique, as would be expected. When a new user is added, the next available UID is usually used, but there's no restriction on having gaps or using order with UIDs. However, if the Unix box is part of a network, it is essential that the person's UID be unique across the network. The same constraints apply to the group ID: in most cases a new group ID equal to the UID is assigned the person. Addition to other groups occurs after the person is added to the system.
The UID of 0 (zero) is the superuser, root. The GID of 0 (zero) is wheel, the superuser group.
The user's name, address, office location, etc. can be included in the comment field, and the default home directory (created before adding the user) and person's startup shell is added to the record.
Adding users varies widely between systems. Apple's Darwin uses a separate system called NetInfo, an open source application (available at http://sourceforge.net/projects/netinfo4unix/) to manage users, groups, directories, and so on. A daemon uses information from NetInfo to control user access; the user "flat files," as passwd and group are known in this system, are used only in single-user environments.
In Linux, Solaris, and other systems, the process of adding a user is simplified with a utility, adduser (or useradd). The simple form of the utility is:
# adduser username
The utility is called with the username of the new user. Based on the system, the user is then added with defaults or you're interactively asked for more information. Or you can specify information on the command line that's used to create the user.
In Red Hat Linux, adduser is an alias for useradd. Default values are used for each user, such as a home location of /home/username and a default shell (bash), unless specified otherwise on the command line. In the following example, a new user, testuser, is added. Command-line options are used to override the default information:
# useradd -c "Test User" -d /home/local/testuser -G 501, 502 -p changepassword -s /bin/bash -e 2002-05-24
In this example, -c is used to add a username comment (the user's full name), -G specifies what groups to add the person to, -p adds a password, -s sets the person's default shell, and -e specifies that the username expires on a certain date. The person is added to their own group 503 in this example. To override this I would use the -g command-line parameter the -G only adds the person to additional groups, it doesn't override default behavior.
Within Mac OS X, user and group management is handled through Netinfo. Find out more about Netinfo at http://www.opensource.apple.com/projects/documentation/howto/html/netinfo.html. The command-line utility to add a user via Netinfo is niutil. An example of its use is:
shelleyp% niutil-create//users/newbie
Use the system's manpages to see if useradd or adduser is installed and the command line parameters supported.
SP
If a person forgets their password, it's easy for root to reset it using passwd, but what happens if you forget root's password?
Depending on the security implemented for a system, you can log in to single user mode and then use passwd to reset the root password. Or you can manually edit the password file to remove the password for root. Once you reboot and login to the system as root, you can then use passwd to change the password to something more restrictive.
In Redhat Linux, access single-user mode by typing linux single at the boot prompt. In Solaris, enter single-user mode by pressing STOP-a and then typing boot-s at the prompt. FreeBSD boots in this mode by booting with the -s option and then mounting the file system in read/write mode. Check your system documentation to see how to do this for your particular flavor of Unix.
This approach works only if the system doesn't password-protect single-user mode. However, if you have access to the physical machine and the installation disks, booting with the install disk will usually allow you access to the partitions. Once you have this access, edit the password file and remove the root password.
As an example, Debian requires a password in single-user mode. To reset the root password with Debian, put the installation disk into the machine and boot. Mount the /root partition and manually edit the shadow file, setting the password to a blank password. After rebooting into the system, reset the password using passwd.
SP
You can use the umask command to set the default mode for newly created files. Its argument is a three-digit numeric mode that represents the access to be inhibited masked out when a file is created. Thus, the value it wants is the octal complement of the numeric file mode you want. To determine this, you simply figure out the numeric equivalent for the file mode you want and then subtract it from 777. For example, to get the mode 751 by default, compute 777-751 = 026; this is the value you give to umask.
% umask 026
Once this command is executed, all future files created will be given this protection automatically. System administrators can put a umask command in the system initialization file to set a default for all users.
You can set your own umask in your shell setup files to override defaults.
AF
If you work on a Unix system with lots of users, you may be taking advantage of Unix group permissions to let users in one group write to files in a directory, but not let people in other groups write there.
How does Unix determine what group should own the files you create? There are (at least!) two ways:
The effective group ID of the process determines the ownership of the files you create. (Your effective GID is your primary group membership unless you're running a SGID program.)
The group that owns the directory in which you create the file owns files.
The system administrator decides which of the methods a filesystem will use for group ownership. There are other wrinkles, too. A good place to look for the gory details is your system's open manpage help, but it's probably easier to just create an empty new file and then check the group ownership with ls -l or -lg.
You may be able to use the directory's set group ID (setgid) bit to control group ownership. In those cases, if the bit is set, the rule in point 2 applies. If the bit is not set, the rule in point 1 applies. To set and remove the setgid bit, use the commands chmod g+s and chmod g-s, respectively.
> chmod g+s mt.pl > ls -l mt.pl -rwxr-sr-x 1 shelleyp shelleyp 1939 Apr 28 22:55 mt.pl
You can use the chgrp command to change a file's group.
> chgrp wheel mt.pl > ls -l mt.pl -rwxr-xr-x 1 shelleyp wheel 1939 Apr 28 22:55 mt.pl
However, you must own the file, and you must also be a member of the file's new group. If you've reset directory mode bits, it's possible to wind up with ls -l permissions that have an uppercase S, like drwxr-S. What's that? (It's often a mistake.) The directory's setgid bit is set, but the execute bit isn't set. If you want the directory to be group-accessible, add execute permission with chmod g+x. Otherwise, you may want to clear the setgid bit with chmod g-s.
JP, SP
Group membership is an important part of Unix security. All users are members of one or more groups, as determined by their entries in /etc/passwd and the /etc/group files.
To find the GID number of your primary group, grep your entry in /etc/passwd:
> grep shelleyp /etc/passwd shelleyp:*:1000:1000:Shelley Powers:/usr/home/shelleyp:/bin/tcsh</screen>
The fourth field (the second number) is your primary group ID. Look up this number in the /etc/group file:
> grep 1000 /etc/group > shelleyp:*:1000:
On my FreeBSD system, my primary group is a group of which I'm the only member, shelleyp. Therefore, when I log in, my group ID is set to 1000.
To see what other groups you belong to, use the groups command if your Unix version has it. If not, you can get groups from the Free Software Directory at http://www.gnu.org/directory/index.html. Otherwise, look for your name in /etc/group:
> grep shelleyp /etc/group wheel:*:0:root,shelleyp webadmin:*:900:shelleyp,burningbird ftpadmin:*:901:shelleyp,burningbird mailadmin:*:903:shelleyp,burningbird sysadmin:*:905:shelleyp,burningbird pkgadmin:*:906:shelleyp,burningbird shelleyp:*:1000:
In the output, you can see that I'm a member of several groups, including wheel, webadmin, and so on. These are my secondary groups. The output also shows that the user "burningbird" is also a member of several of the same groups as myself.
On BSD-derived Unix systems (OpenBSD, FreeBSD, Darwin, and so on), you're always a member of all your groups. This means that I can access files that are owned by webadmin, wheel, and so on, without doing anything in particular. Under System V Unix, you can only be "in" one group at a time, even though you can be a member of several.
Within System V and Linux, if you need to access files that are owned by another group, use the newgrp command to change your primary group:
> newgrp groupname
The newgrp command starts a subshell. When you're done, type exit to leave the subshell. newgrp can be important for another reason: your primary group may own any new files you create. So newgrp is useful on any system where you want to set your group (for creating files, for example, when you aren't using a directory that sets its own group). If you can't use newgrp, the chgrp command will change a file's group owner.
The ls -l command shows a file's owner (and, in many versions, the filefs group too; if yours doesn't, add the -g option). The GNU ls -nl option shows a file's numeric UID and GID instead of the username and group name:
$ ls -l total 38 -rw-r--r-- 1 root weblog.burningbi 33922 May 23 13:52 access_log -rw-r----- 1 shelleyp weblog.burningbi 3995 May 12 11:08 analog.cfg -rw-r--r-- 1 root weblog.burningbi 0 May 23 12:01 error_log $ ls -ln total 37 -rw-r--r-- 1 0 501 32890 May 23 13:50 access_log -rw-r----- 1 1000 501 3995 May 12 11:08 analog.cfg -rw-r--r-- 1 0 501 0 May 23 12:01 error_log
(System V-based Unixes even let you change to groups that you don't belong to. In this case, you have to give a group password. Group passwords are rarely used: usually the password field is filled with a *, which effectively says that there are no valid passwords for this group.)
On most systems, there are groups for major projects or departments, groups for system administration, and maybe one or two groups for visitors. BSD-based systems often have a wheel group; to become root, you must belong to wheel. Many systems make terminals writable only by the owner and a special group named tty; this prevents other users from sending characters to your terminal without using an approved setgid program like write.
JP, SP
Usually, Unix group access allows a group of users to access a directory or file that they couldn't otherwise access. You can turn this around, though, with groups that deny permission.
This trick works only on Unix systems, like BSD (FreeBSD, Darwin, OpenBSD, and so on), that let a user belong to more than one group at the same time.
For example, you might work on a computer that has some proprietary files and software that "guest" accounts shouldn't be able to use. Everyone else on the computer should have access. To do this, put the software in a directory owned by a group named something like deny. Then use chmod to deny permission to that group:
# chmod 705 /usr/local/somedir # ls -lgd /usr/local/somedir drwx---r-x 2 root deny 512 Mar 26 12:14 /usr/local/somedir
Finally, add the guest accounts to the deny group.
Unix checks permissions in the order user-group-other. The first applicable permission is the one used, even if it denies permission rather than grant it. In this case, none of the guest accounts are root (we hope!).
They're members of the group called deny, however; that permission (---) is checked and the group members are shut out. Other users who aren't members of deny are checked for "other" access (r-x); they can get into the directory.
The same setup works for individual files (like programs). Just be careful about changing system programs that are SUID or SGID.
JIK
Scripts may need to run within a root environment but be executed by system users other than root. To allow a nonroot user or group of users executable access of the script, its SUID or SGID bit can be set.
The SUID bit is set using the following command:
chmod u+s somefile
Running ls -l on the file afterwards displays the following (within FreeBSD):
-rwSr--r-- 1 root somegroup 7219 Oct 29 2001 somefile
Now, any user can execute the file, and the file runs with root permissions.
A more restricted version of SUID is SGID, set as follows:
-rwx-r-Sr-- 1 root somegroup 7219 Oct 29 2001 somefile
Users belong to the specified group, somegroup, can execute the file now, and it runs with root permissions.
As handy as SUID and SGID scripts are, they are also dangerous. For instance, SUID scripts are considered so dangerous that the Linux kernel won't even honor them. This is because environmental variables are easily manipulated within scripts, particularly C shell scripts, as discussed in Section 50.9. And since the scripts can be run by anybody, and run as root, they represent extreme points of vulnerability.
To see where you have SUID and SGID scripts, use the following command (pulled from the Linux Security HOWTO document at http://www.cpmc.columbia.edu/misc/docs/linux/security-howto.html):
find / -type f \( -perm -04000 -o -perm -02000 \)
To do a thorough scan, you need to have root permissions.
You'll be surprised at the number of applications returned from the search. Among those in my FreeBSD system were:
/usr/virtual/share/usr/sbin/pstat /usr/virtual/share/usr/sbin/swapinfo /usr/virtual/share/usr/sbin/sliplogin /usr/virtual/share/usr/sbin/timedc /usr/virtual/share/usr/sbin/traceroute
However, a quick check shows that the files sharable across different FreeBSD installations are all SGID: not as dangerous as SUID files long as the group is restricted.
SP
You don't have to login as a specific user you can login as yourself and then issue a su command to login as another person.
Invoke su with a username and you'll be prompted for that person's password. If you invoke su without a username, the system logs you in as root and asks you for root's password. Without passing in any other flags, you'll be logged in with your environment variables, except for HOME, SHELL, and USER. If you want to emulate the full environment of the user for debugging purposes or whatever use the -l flag with su:
bash-2.04$ su -l Password:
Using su to emulate another person's account is an effective debugging solution if you're trying to determine why a person is having problems accessing an application. In addition, it's also an effective way of logging into root without logging in from a console or remotely from another machine or terminal.
You exit the su shell by typing exit or hitting CTRL-d.
SP, JP
The easiest way to allow a cracker into your system is to provide external root login access. In particular, if you allow root access through an unprotected and open protocol such as telnet, you're almost guaranteeing that your Unix box is going to be violated at some point.
To prevent this, most Unix systems don't allow remote login into the system as root. Instead, you log in under another username and then su to root once you're within the system.
Disabling root access differs between systems. If your box has an /etc/securetty file, this lists ttys that allow root access. Removing this file or removing its contents will disable root access.
In Solaris, a line within /etc/default/login file is commented out if remote root login is allowed:
#CONSOLE=/dev/console
Uncomment the line to allow root access through the system console. To completely disable console access, remove the /dev/console from the line:
CONSOLE=
SP
You may not want to give people access to the root password just to give them access to specific superuser powers. In cases such as this, you should consider using sudo an application that enables specified users to execute applications that normally require root privileges.
The sudo application isn't installed by default on all systems, but it is available for most. You can find out if it's installed on your system by typing sudo at the command line. If it isn't installed, check online for versions that run on your machine. The application's home is at http://www.courtesan.com/sudo/index.html.
The sudo configuration file is called sudoers and is installed in the /etc subdirectory. In Darwin, the default sudoers file has the following settings:
root ALL=(ALL) ALL %admin ALL=(ALL) ALL
In the file, root has open access to all applications. In addition, all members of the admin group (equivalent to wheel within Darwin) can also run all commands.
Without getting into too much detail (an online sudoers manual is at http://www.courtesan.com/sudo/man/sudoers.html), the sudoers file can consist of a set of aliases, used to define groups of people, commands, hosts, or run as options. It then defines rules by which specific users or group of users can run specific commands. There are four types of aliases:
List of specific users
List of users to emulate
List of servers
Command list
Examples of aliases are:
User_Alias SYSADMINS = shelleyp, mike, tomd Runas_Alias OP = root Host_Alias BB = burningbird Cmnd_Alias SU = /usr/bin/su
Following the aliases are override rules in reference to system defaults. For instance, warnings and "lectures" can be attached to certain commands to ensure that people are aware of the repercussions of their actions. However, people who are sysadmins shouldn't be subjected to these rules; the lectures can be turned off for them:
Defaults:SYSADMINS !lecture
Neither aliases nor default overriding rules are required in the sudoers file. The only statements that are required are the command rules. In the Darwin file, the rules allowed root and admin access of all commands. Other rules that can be created are:
# sysadmins can run all commands, without password SYSADMINS ALL = NOPASSWD: ALL # chris can run anything on the burningbird machine as OP (root) chris BB = (OP) ALL # joe can run SU on burningbird as root joe BB = (root) SU
To edit the sudoers file, you use a specialized editing tool, visudo (see manual at http://www.courtesan.com/sudo/man/visudo.html), while logged in as root. The editor prevents collision between multiple authors and also verifies the correctness of the edits.
To work with sudo (manual at http://www.courtesan.com/sudo/man/sudo.html), type sudo and the command you want to exit:
% sudo vi test
Depending on your setup, you'll get a warning or a password prompt, or the command will fail or execute.
One interesting side effect of sudo is that if you allow root access to an application that has shell escape, such as vi, you are indirectly giving that person access to a root shell. Use sudo with caution.
SP
The majority of Mac OS X users are never going to access the built-in Unix Terminal and never directly access the Darwin core of the operating system. Instead, they'll work within the GUI. However, Mac OS X developers and superusers will operate directly with Darwin quite extensively, and at times, they'll need to have root access.
By default, root access in Darwin is disabled. Trying to use su to change to root within the Terminal will fail. You have to enable root first using NetInfo.
To enable root within Mac OS X, access the Go menu option of Finder, and double-click on Applications. When the Applications window opens, double-click on the Utilities folder. In this folder, select and open NetInfo.
When NetInfo opens, select the Domain menu item and then Security. You'll need to authenticate yourself to the system first by selecting the Authenticate submenu option. Once you provide a password (and the system determines you have the authority to enable or disable root), accessing the Security menu again will show a newly enabled option: Enable Root User. Clicking on this enables root. However, you'll need to reauthenticate one more time to ensure the change goes through.
Once root is enabled for the system, it stays enabled until you disable it again. With root enabled, you'll be able to use su to login as root.
SP
You can temporarily disable logins by creating an entry in /etc/nologin (Section 3.1) and copying a message to this location. When a user attempts to log in, he will get this message and the system will prevent entry.
SP
| CONTENTS | |