| Previous | Table of Contents | Next |
Two additional permission bits are associated with a file: the SUID and SGID bits. SUID stands for Set User ID, and SGID is Set Group ID. Programs with these permissions behave as though they were owned by different UIDs when they’re run. When an SUID program is run, its effective UID is set the same as the user that owns the program on the file system, regardless of who is actually running the program. SGID is similar except that it changes the group ID instead.
Although the SUID/SGID feature can be useful, it can present a big security hole. SUID programs are generally used when a program needs special permissions, such as root permission, to run.
Programmers usually go to great lengths to ensure that their SUID programs are secure. Most security holes in SUID programs occur when the program executes a command line, activates a shell, or runs a file that users can change to contain their own commands. Although some SUID programs are necessary, you should try to keep them to a minimum. You should also regularly scan your file systems to check for new SUID programs by using the find command (refer to the man page for the exact syntax).
With all the different security features available on a Linux system, the biggest security hole is typically your users. After all, your users already have valid accounts.
But what does this have to do with social engineering? What is social engineering, anyway? Social engineering is about convincing people to do what you want, either by playing on their assumptions or behavior, or by outright misrepresentation and lying. People, in general, want to be helpful. And, if given the opportunity, they usually try to help out as much as possible. Crackers with good social engineering skills play on this characteristic.
Assume that you have a computer user named Mr. Jones. He’s just your average user—not a guru at all. One day, Mr. Jones gets a call at the office that goes something like this:
| Mr. Jones: | Hello? |
| Caller: | Hello, Mr. Jones. This is Fred Smith in tech support. Due to some disk space constraints, we’re going to be moving some user home directories to another disk at 5:30 this evening. Your account will be part of this move and will be temporarily unavailable. |
| Mr. Jones: | Uh, okay. I’ll be home by then, anyway. |
| Caller: | Good. Be sure to log out before you go. I just need to check a couple of things. What was your login ID again—jones? |
| Mr. Jones: | Yes, it’s jones. None of my files will get lost during the move, will they? |
| Caller: | No sir. But I’ll check your account just to make sure. What was the password on that account so I can get in to check your files? |
| Mr. Jones: | My password is tuesday. |
| Caller: | Okay, Mr. Jones. Thanks for your help. I’ll be sure to check your account and verify that all the files are there. |
| Mr. Jones: | Thank you. Bye. |
So what just happened here? Someone called one of your users on the phone and managed to get both a valid user name and password in the course of the conversation. And you guessed it—if Mr. Jones calls tech support tomorrow, he’ll probably find that no Fred Smith is working there!
How do you prevent things like this from happening? Educate your users. Your users should never give out a password over the phone to a caller. They should never leave one on e-mail or voice mail. Crackers use social engineering by convincing users to give them what they want; they don’t even have to try to break into your system.
Linux verifies your identity by your login ID/password combination. As you log in, your process is tagged with an ID that identifies you to the system. It’s this UID that’s checked for file and directory access.
Linux offers the capability to switch to another UID while you’re working. When users use the su command, they can become root or another user. They must know the password of the user that they’re changing to. For example, for a user to change user ID to that of user ernie, the command is
su ernie
The user is then prompted for the password associated with the login ID ernie.
To change to root, the command is
su root
The user is then prompted for the root password.
Typically, all attempts at using su are automatically logged in a system logfile, such as /var/adm/syslog. Examine this file periodically to check on this sort of activity.
Along with power comes responsibility. If not handled carefully, Linux’s power to share information, processing resources, and peripherals can leave your system open to abuse. Your job is to set up system security so that only the right users and systems can connect to yours, and that they can use only the parts of your computer you want to share.
You can monitor your system for security threats. To determine who is using your system and the type of work they’re doing, use the ps command.
Be wary of jobs that seem to be running a very long time or users who seem to be using more resources than normal. These can be an indication that a login has been compromised and an unauthorized user is running a program to guess passwords.
| Previous | Table of Contents | Next |