Welcome to post 28 of my 100 day challenge. Checkout my introduction for some background.
This is post twelve of my LFCS series. In this post we will discuss local security on Linux specifically accessing the root account and using sudo to manage access to the root account.
This post is quite long so you might want to set a side some time to go through it properly.
Accessing the root account
If you want to change the user of the current login session you can use the su (Substitute User) command. You can find out what user is currently logged in via the whoami command. Or on CentOS distributions it is part of the shell prompt and appears to the left of the screen. Below I will change the login session from the mytest user to the centostest user by using su.
[centostest@centospractice /]$ whoami centostest [centostest@centospractice /]$ su mytest Password: [mytest@centospractice /]$ whoami mytest
If you login as another user using just su you maintain the variables of the previous user instead of switching to the variables and environment of the destination account. If you wanted the full environment for the mytest user you would have to add in the – switch. For all intents and purposes it would be as if you logged in directly as the mytest user:
[centostest@centospractice /]$ su - mytest Password: [mytest@centospractice ~]$
If you wanted to change to the root user you could still use su but with the – switch to gain the full root environment essentially emulating a full login of the root user:
[mytest@centospractice ~]$ su - root Password: [root@centospractice ~]#
Using sudo to manage access to the root account
There is another package which is useful when wanting to run things as the super user. This package is sudo. It is usually installed by default but you can install it via yum. It allows you to run a command as another user. Allowing a user to run a program with the security privileges of the super user or another user with higher privileges.
Who has sudo access?
There is a file in Linux which handles who can sudo. It lives in /etc/sudoers. The setting in this file dictate who has access to sudo on the system. You can also add your own config files to /etc/sudoers.d and it will be picked up by sudo when you execute it. This is useful to split up permissions in a more consumable format. It is generally good practice to put system specific config in there and leave the default config file alone as this can be overwritten if you upgrade your operating system.
If you had a group centostest and wanted the members of it to have full access to the super or root users. You would add the following to the sudoers file:
%centostest ALL=(ALL) ALL
There is usually the following entry there already:
root All=(ALL:ALL) ALL
The above means that the root user and anyone in the groups (group is denoted by %) have full access to the entire system and its contents.
You should be able to see the line:
# %wheel ALL=(ALL) ALL
If you remove the leading # then the rule is activated.
If you want to give a user full rights to the system then you can add them to the wheel group. You can also add them manuall via /etc/group. You have to be root or a user that has been granted sudo abilities to do this.
If you ever need to edit the sudoers file or any subfiles in /etc/sudoers.d I would highly recommend you use the visudo command. This command opens the config file in vi/vim and will validate your entries before saving believe me this will save you a lot of pain in the long run.
This concludes my article on local security. Check back over the next few days for my articles on software management, other useful tools and bash shell scripting.
Can you improve on any of the tips I’ve discussed here? If you can let me know in the comments.