This tutorial will cover the steps for adding a new, unprivileged user for day to day use of BackTrack. It will also discuss the reasons for and against running as root, as well covering off on as potential problems that may arise from running as a user other than root and how to solve these problems.
This is essentially just a repost of a tutorial I posted over at the BackTrack forums here, and I wanted to include a copy here on my blog as well.
Why Create an Unprivileged User?
Before we discuss the "how" of adding this new user to BackTrack, lets first go over the issue of "why" you might want to do this, or why it is even necessary to add an unprivileged user to BackTrack. In this section we will discuss some background issues to give us some perspective on the issue, and we will also cover off on the positive and negative factors of running BackTrack using an unprivileged user.
Most Linux systems currently available today are designed to be run in every day use as a user other than root, with the user being prompted to setup at least one of these users during the installation routine. There are important security and stability reasons for this decision, which become even more important when the system is run as a multi user system, where more than one person uses the same Linux system.
BackTrack is different. Due to its roots as a live system, and considering that it has a large number of tools installed that need to run using root privilege, BackTrack is designed to run as root.
In addition, taking into account that BackTrack is a distribution aimed at security professionals, it is assumed that BackTrack's users will be aware of the risks inherent in running a system as the root user. Your average Linux system is not usually made with this assumption in mind.
Given that "security" is generally mentioned as the deciding factor as to why you shouldnt run a Linux system as root, it might be helpful for us to actually examine the specific risks that are involved, so we can make an informed choice about whether to run as root or not.
So what are these risks? Well they fall into two main categories:
- Things that you might accidentally do yourself, and
- Things that an attacker might do using your own privileges.
As an example of what you might accidentally do to yourself, if you run "rm -rf /*" as root, you can kiss your system and all data on your mounted volumes goodbye. If you do this as a regular user instead of root, any of your own personal files will still be deleted, but your system should still survive. So not running as root limits the damage you can do to your system. This factor is particularly important in multi user systems, as it stops one user from accidentally breaking a system used by others. Even if it's only you using the system however, it's still nice to know that one mistyped command won't be the end of it.
As an example of what an attacker might do, if you happen to visit a malicious website hosting a Linux exploit while running as root, that exploit will have full access to your system. Running as root, that exploit will be able to do a much wider variety of "bad things" than it could if you were running as a regular unprivileged user. While Linux client side exploits aren't exactly that common in the wild, they are still not unheard of, and their prevalance will grow along with the use of Linux on the desktop, so this is something that should not be totally discounted.
Now those are the "security" related reasons related to use of root on a BackTrack system, but there are some other factors to consider as well:
- If you are only using BackTrack as a Live environment, and are not installing it to a hard drive, then there really isnt much point in using an unprivileged user. The threat of accidentally destroying your system by running a privileged command no longer really applies, as the system will be regenerated from the ISO once you reboot, and any malware or attacks
- If you spend most of your time in BackTrack running privileged commands (changing networking settings, sniffing traffic, binding to low numbered ports, etc), you may also believe that the extra added inconvenience of logging on as a unprivileged user is not worth the bother.
- In addition, running as root is what long time users have come to expect from the system. Most of the tutorials you see on this forum or elsewhere on the Internet are likely to have been written to assume that you will be running as root, so if you aren't you will need to be able to adjust the commands you run as appropriate. I will go over some guidelines on how to know if a program needs to run as root later in this HowTo.
So those are the things you will want to consider when deciding whether or not to add an unprivileged user to BackTrack.
Starting to Create the New User
Now we have discussed the factors that would influence your decision on whether or not to create a unprivileged user in BackTrack, lets discuss how you actually go about doing it. The following steps assume that you have installed BackTrack 4 Final to a hard disk and have booted into this new system.
Fixing up /etc/skel
The first thing we will do before creating our new user is to fix up the /etc/skel directory. We will be using the adduser script to create our new user, and when a new user is created on a Linux system using this script the files from /etc/skel will be used as a template for creating the new users home directory. We will modify the files here so that our new user, and any subsequent users we create using this method have the correct files copied to their home folders.
The commands below will prepare our /etc/skel directory.
This command gives us the correct menus for our new user:
root@bt:~# cp .config/menus/applications-kmenuedit.menu /etc/skel/.config/menus/
These commands set the desktop folder for new users to /home/
root@bt:~# sed -i 's/XDG_DESKTOP_DIR="$HOME\/"/XDG_DESKTOP_DIR="$HOME\/desktop"/' /etc/skel/.config/user-dirs.dirs
root@bt:~#mkdir /etc/skel/desktop
This command sets the fancy new desktop wallpaper for new users:
root@bt:~# sed -i 's/Wallpaper\[\$e\]=\/opt\/kde3\/share\/wallpapers\/origin2.jpg/Wallpaper\[\$e\]=\/opt\/kde3\/share\/wallpapers\/bt4.png/' /etc/skel/.kde3/share/config/kdesktoprc
These commands set the BackTrack dragon icon in the KDE menu:
root@bt:~# cp .kde3/share/icons/nuvoX_0.7/kmenu-dragon.zip /etc/skel/.kde3/share/icons/nuvoX_0.7/
root@bt:~# unzip -ou .kde3/share/icons/nuvoX_0.7/kmenu-dragon.zip -d /etc/skel/.kde3/share/icons/nuvoX_0.7/
And this command copies over some some other configuration files for various programs install with BackTrack:
root@bt:~# cp -R /root/{.wine,.maltego,.conky_scripts,.liferea_1.4,.gem} /etc/skel/
Creating the User
Now /etc/skel is configured appropriately we can actually create the new user, using the following command, where [user]
root@bt:~# adduser[user]
This command is actually a script that makes use of a number of other Linux tools to create your user and set up all of the necessary options for the account. The script will prompt you for a number of pieces of information about your new user account, some of which are optional. I have included an example session, where I created a "lupin" user, below.
root@bt:~# adduser lupin
Adding user `lupin' ...
Adding new group `lupin' (1000) ...
Adding new user `lupin' (1000) with group `lupin' ...
Creating home directory `/home/lupin' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for lupin
Enter the new value, or press ENTER for the default
Full Name []: lupin
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
This command will add the user to the admin group, which will allow it to use the sudo command. Replace
root@bt:~# usermod --groups admin,disk,cdrom[user]
Once these commands have been run, restart your system and logon as your new user, using the password you set when prompted by adduser. The first time you logon, you will get a message popping up about krandrtray which you can safely cancel.
Using Your BackTrack System with a Non Privileged User
Now, given that BackTrack is designed to run as root a number of the programs you see in the menu or see mentioned in tutorials will not work when run using your new user account. For these programs, you will you know how and when to use su, sudo or kdesu to escalate your privilege so that the programs can run properly. Now Im not going to go into the details of how to use su, sudo and kdesu - you can check the man pages or one of the many tutorials available on the Internet to discover this. I will, however, briefly discuss how to know WHEN to use them, that is, how you can determine when root privlege is required.
So how do you know when root privilege is required? Well, anything to do with administration of the system requires root privilege, and this includes tasks such as loading kernel modules, modifying system wide settings or network configuration etc. Other programs will mention in their documentation that root privilege is required, or they will straight out tell you when you try to start them that they need to run as root. Any errors mentioning privilege or permission are also a good sign that root may be required. Also, if a program just isn't giving you the results you expect, you can try running it as root as part of a troubleshooting process. Lack of root privilege may not always be the reason why the program isn't doing what you want, but it's worth ruling out as a possibility.
One more thing I will briefly cover off on is how to edit the menu entries of programs that require root privilege so that they run properly using your unprivileged user. Now I rarely use the menu, preferring instead to just start most things from the command line. Here I can use su, sudo or kdesu as appropriate to start up any programs or perform any tasks that require elevated privilege. For things I do like to run from the menu however, I edit the menu entry by right clicking on it, selecting "Edit Item" from the context menu, and clicking on the "Run as different user" tick box in the KDE menu Editor entry for that menu item, and then typing in root as the Username. Now when that menu item is selected you should be prompted for your password when it starts, and it will execute with root privilege. There will be some programs for which this method does not work, for these programs you will need to find an alternate means of running them.