Securing root access by configuring SUDO

  In previous blog posts, we have enabled and used the root account to make changes to important *nix configuration files to tweak the system to perform in a manner more to our liking. For example in preventing the mounting of un-needed Windows volumes while using Mac OS X. https://www.catracing.org/hendrb/?p=32 (Suppressing auto mount of volumesin OS X with /etc/fstab). I mentioned that using the root account was not an accepted best practice. So what is considered “best practice”? How are you supposed run commands, or edit important system files that require root access?

Also in the previous article I introduced you to the command su, Which coincidently stands for “Switch User”, not “superuser”, don’t believe me?  SU will allow me to switch to any user on the system, and inherit the rights of that user, not specifically “SUPER USER” access. In todays article I will introduce you to another command, sudo. Or switch user do. (In Windows this would be equivalent to the RUN AS option).

Lets first take a look at sudo in an OS X terminal session. I will open up the file /etc/hosts in vi as a normal user. (Using the absolute path)

 prompt$ vi /etc/hosts

 ##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##

127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0     localhost
~                                                                              
~                                                                              
~                                                                              
~                                                                              
~                                                                              
~

“/etc/hosts” [readonly] 17L, 445C

Notice that the file was opened as read only?, this is because my normal user account does not have access to write to the /etc/hosts file. While we could su to root, then issue the vi /etc/hosts command, this is considered poor practice, and frowned upon. Best practice stipulates that you should always login with an account with the least amount of privileges, and use a privileged account only when needed (Some system admins actually recommend that you disable the ability to login with the root account anywhere but from the actual server console.) This not only protects your workstation from hackers getting root level access, but protects you from doing something stupid. Like accidently deleting important files or directories.

Let’s take a look at CentOS, and discuss how to configure SUDO.

$ sudo vi/etc/hosts

user Is not in the sudoers file. This incident will be reported!

Uh Oh!! What did we do? No need to panic, or plan on leaving the country! This is completely normal. We have not yet configured the system to allow your account to use the SUDO command.

In order to configure sudo, we need to edit a file called /etc/sudoers. However there is a catch. You do not want to just edit the sudoers file in any old text editor (You are even told this in the man file for sudo!) Instead we will use the visudo command, which loads the /etc/sudoers file into vi for us. Yes you will first have to su to root. It’s okay!! This will be the last time you will be doing this on your system. GO FOR IT! I won’t tell anyone!

Now that you have switched to the root account, there are 2 ways we can go about allowing your user account use the sudo command. The simplest method is simply adding your username to the file. Which we will discuss first, which will work with a stand alone desktop with only one or two users. The second method, which is best practice for a server with multiple users is to add a group to the system, and configure the sudoers file to allow members of that group access to the command. This way instead of having to modify the file each time you want to grant a user sudo access. You just add them to the member of the group.

So let’s get in to method #1.

First su to root.

$ su –
Password:

(enter your root password)

Now type visudo

# visudo

You should now see the sudoers file loaded into the standard vi editor.

Look for the following line.

 ## Allow root to run any commands anywhere
root     ALL=(ALL)                  ALL

Use your cursor keys to position the cursor underneath this line, then enter insert mode by pressing I, the add the following.

 <username>  ALL=(ALL)                  ALL

Enter command mode by pressing ESC, then write the file and quit with the :wq command. You should now log off the system, and back in so the new SUDOERS file is reprocessed.

Now test that the file was edited correctly, by trying to edit the /etc/host file with the sudo command.

 $ sudo vi /etc/hosts

You should be prompted for your password.

password:

Enter YOUR user password. If everything is successful, you should now be in vi, with /etc/hosts loaded. You should not see the file being read only this time.

Quit vi by entering q

Now lets looks at the second method I mentioned above (This time dealing with CentOS Linux), For OS X users, simply create the group sudo using System Preferences > USERS and GROUPS, and add it to your user account, and skip to step 2.

For those using Linux switch your user account to root (Or use sudo if you completed the steps above.)

 $ su –
 password: <Enter root password>

We will now create a new group called sudo (I will not be using any options, if you wish to know more about this command, check out it’s MAN entry)

 # groupadd sudo

We now must add the new group sudo your user account as a supplemental group.

 # usermod -a -G sudo <username>

Option -a appends a supplementary group to the specified user account, this MUST be followed by the -G option.

The name of the group we are adding is the newly created group called ‘sudo’, followed by the name of the user account. Note: You can add multiple supplementary groups here with the group names separated by a comma ‘,’.

We can verify that the group was successfully added to the user by the following command.

  #groups <username>

You should see list of the groups the user is a member of, including the newly created group sudo.

The last thing we need to do to wrap this up, is go back into the /etc/sudoers file and add the sudo group.

 #visudo

Look for the following text.

##Allows people in the group wheel to run all commands.
# %wheel       ALL=(ALL) ALL

Move your cursor below the above line, and enter INSERT mode by pressing I

Add the following line to the file.

%sudo          ALL=(ALL)ALL

Hit ESC to enter command mode, save and exit VI, by entering :wq

You can now control who has full SUDO access, simply by adding the user to the group sudo.

There is one more item I would like to cover regarding the SUDO command. By default, you can use sudo for 10 minutes before you are prompted to enter your password again. I consider this poor security. If you leave your computer without closing your terminal session, anyone who comes along has full access to your system. You can modify the system so that it will always prompt for your password each time you use SUDO. Which I recommend that you do.

If you are still logged in the terminal session as root, enter the exit command, this should take you bcak to your normal user account, which should be noted by the $ prompt.

$ SUDO visudo
password: (Enter YOUR password here).

You should now be in VI with the /etc/sudoers file loaded. Find the line of the file that says defaults reset.

At the end of the line enter INSERT mode by typing i, add ,timestamp_timeout=0
Exit insert mode by hitting ESC, and enter :wq

Now each time you use the SUDO command, you will be prompted to enter your password.

Congratulations, you are now using best practices when executing commands using elevated privileges.

I hope you enjoyed this blog post!

Suppressing Autmount of Windows Volumes in OS X

Well I did promise to post another article, once I figured out how to suppress the auto mounting of unwanted volumes using /fstab (In this case, my Windows volumes.). I could not for the life of me figure out why all the articles on the web pointed to being able to use /etc/fstab with the noauto parameter set, but I could not get it to work for me.

Amazing what will pop into your head at the strangest time when you step away from the problem. In this case it was 8am Sunday morning that I realized the blog articles I was reading were written for BootCamp partitions on an HFS volume (One of the limitations of BootCamp is that it does not support booting from an external Hard Drive)!  Old Style Mac Pro’s can have 4 internal drives.  So my Mac Pro can actually use native NTFS internal hard drives! I was specifying that the volumes were HFS per instruction. and not NTFS!. NTFS stands for NT File System, which Windows has used since Windows NT 3.1 (Which was the first version of NT released to the public.) HFS or Hierarchial File System, or in our case HFS+ is the file systems used on Macintosh computers, since way back in 185.

So I jump out of bead, wake up my trusty Mac, log into a terminal, su to root, redo the changes to /etc/fstab. Enter the reboot command and VIOLA! Success, and the bitter feeling of failure since I spent almost an entire day working on this and missed such a small but crucial change that should have been obvious.

What we need to do is edit the /etc/fstab file (Apple recommends not using this file for some reason. Actually, they recommend not using allot of the Unix level files, but I think that’s just silly. You have a very powerful and configurable OS under the hood. Take advantage of it.

Go ahead, open up that scary terminal window!! Come on, Steve put it there for a reason!

1)   The first thing we need to do is find the UUID of the volume you no longer wish to mount. (Sounds hard huh?) No EASY.. Check this out. Type in your terminal window.

 Shell_prompt$ diskutil info (Drag the disk volume onto the terminal window)

Note: If you have a volume name with spaces in to, you will either need to surround the full path in single or double quotes. (IE: “/Volumes/Macintosh HD” or surround the item with the space with a \ (IE: /Volumes/Macintosh\ HD\).

You should now see something like this > diskutil info /Volumes/BOOTCAMP <Verify command and hit ENTER>

Your output should look something like this.

Device Identifier:       disk0s1
Device Node:             /dev/disk0s1
Part of Whole:           disk0
Device / Media Name:     Untitled
Volume Name:             BOOTCAMP
Mounted:                 Yes
Mount Point:             /Volumes/BOOTCAMP
File System Personality: NTFS
Type (Bundle):           ntfs
Name (User Visible):     Windows NT File System (NTFS)
Partition Type:           Windows_NTFS
OS Can Be Installed:     No
Protocol:                 SATA
Volume UUID:          640E8804-B7C7-4D1C-BBBE-870EAFC9F916

I have removed blank lines, and other fields for brevity.

Now we need the volumes UUID. Do you see it? Simply highlight and copy the data in the terminal window.

Hint: You can also pipe the output through the grep command, and display only the UUID.

EXAMPLE: $ diskuitl info “/Volumes/Machintosh HD” | grep UUID

Your output should look like this.

Volume UUID:            B5CF2066-279C-36B2-B704-2E5B80322313

Now, su to root, or for those Unix GURU’s who are gasping and screaming NO!!!!! sudo vi /etc/fstab.

Hint: If you are pretty sure you have enabled the root account, and your using the correct password, and OS X is still not letting you su to root. Make you first su to an account that has Administrator privileges! Quiz: Anyone who can comment to this post and tell me what “su” stands for in Unix/Linix get’s a point.

So now, picture us on a desert island… I mean… in vi…..   If you are using the current version of OS X (Mavericks), there is no /etc/fstab. You are now in a new file. Throw some comments in there!

(For you non VI people) – Hit I to enter insert mode.

Now on a blank line enter.

##fstab file, created to suppress mounting of specific volumes in this os version.
## Brent Hendricks is Awesome!
## 08/NOV2013 BPH

I always like to put comments in the file, of when and why I have created or made changes to a file. If I have to troubleshoot it really saves time.

Now for the meat! (It’s always about the meat people!)

UUID=640E8804-B7C7-4D1C-BBBE-870EAFC9F916 none ntfs ro,noauto

Your done! Simple huh? How just write the file.

NOTE: I have put the ntfs line here as ro, because by default OS X can not write to an NTFS partition. If you are making an HFS volume not mount at startup. You can enter rw here (For Read/Write)

(For your non VI people, hit (ESC) to exit INSERT mode, type : and wq)

Reboot your system, and notice the specified volume no longer mounts. If you have other volumes you with to suppress automount, repeat the steps above, just add the new UUID on a separate line in the /etc/fstab file.

   OS X: Changing Incorrect Hostname
                         Using The Terminal.

 

 

I have seen this issue many times.  My OS X workstations receive the wrong hostname after being joining a Windows Active Directory Domain, and I have also read this can also happen on a standalone network, though am not quite sure what the circumstances might be as I have never operated outside a domain environment. You would not normally notice this, unless you frequent the Terminal.

You will notice, if you go to System Preferences > Sharing, it appears the hostname is set correctly. For example, the Computer Name shown here is the correct name, correct-hostname.

Now let’s open the terminal.app

You will see from the prompt, that your workstation has picked up the hostname of another computer on the network. It might look something like this, “Incorrect~ user$”

  As you can see, the hostname is different than what displayed in the Sharing Preference Pane.

We Can verify this by entering the hostname command in the shell window.

           prompt$ hostname

The shell returns the system hostname as:

   incorrect-hostname.catracing.org

We know that’s incorrect, don’t we?

We could TRY and change the hostname by entering the terminal command hostname <correct-hostname.catracing.org>. However this will be lost upon reboot. Which would be quite pointless. We could also place it as a launchd item, or put it in a ~/.profile script. However there is a much cleaner and more appropriate method of doing this.

If you have SUDO configured (Which is the best practice)

At the terminal window, type the following.

Prompt$ sudo scutil –set HostName <newhostname>

Do not type the <>’s

If you do not have sudo configured, but have root enabled, su to root (Since I am in a domain environment, and my standard user account does not have administrator privileges I must first su to an account that does have administrator privileges either on the domain or a local administrator account.

Prompt# scutil –set HostName correct-hostname.catracing.org

Now type hostname at the terminal prompt

You should see

correct-hostname.catracing.org
Prompt$

Your actual terminal prompt may not change until you exit and relaunch the terminal.app