Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
A name is a name (ie apps don't check against "name" but ask for a function to return effective uid etc), but what did you have in mind with it if I may ask? Renaming is in the category of "security through obscurity", in some circumstances counted as a deterrant, this easily turns into a false sense of security.
You have a good point there. A false sense of security, hummm : do ya' mean that someone that really knows how to detect root priviledges' would not really attempt to logon as root and 'chip' away at the password, but would rather attempt more obvious routes of control?
Wouldn't any additional security measures, such as changing the named "root" confuse the first attempt probing of a system since most would expect root to exist?
What do you think is the best way to 'cloak' root. or is it necessary.
I guess the important point is to not look at the root account as the userid that has the nameroot (a static attribute w/o impact), but to see it as the userid that has ownage over privileges like POSIX capabilities (CAP_SYS_MOD or the ability to handle module loading, CAP_OVERRIDE or the ability to override file access restrictions, to name just two of the 27). So, you can change the name but the other attributes stay. (I finally get to say "ergo") Ergo, "security through obscurity", cuz nothing important changes.
Take away the capabilities and, in some cases, even root can't regain these capabilities w/o reboot (quite nasty with some caps). Changing capability usage you can do with different approaches like Grsecurity or LIDS kernel patches, or a binary like lcap with which you can take away, say CAP_SYS_MOD, after bootup.
*If you're gonna play with caps, be sure to read for instance lcap's README or another doc on caps.
Take away the capabilities and, in some cases, even root can't regain these capabilities w/o reboot (quite nasty with some caps). Changing capability usage you can do with different approaches like Grsecurity or LIDS kernel patches, or a binary like lcap with which you can take away, say CAP_SYS_MOD, after bootup.
*If you're gonna play with caps, be sure to read for instance lcap's README or another doc on caps.
lcap is a really nice proggy to deal with when securing a server. I'll add it to my security tools section for now It's nice that it checks the capabilities currently avaible and lists them, etc - quite helpful - especially the kernel module capabilitiy checking
keep in mind, stuff like "su" will break in the traditional sense, you'll have to do a
su -u <whatever you wanted root to be called>
as stated above, this really doesn't provide much in the way of sekurity. Logging in as your re-named root is still very very bad, any exploits aren't going to be looking up the UID of root, and if you are so worreid about people trying to brute force your root password...well you might just want to set a good password and look at your logs...
And the reason su fails must be because it uses the getpwnam(3) library routine to look up root by the name 'root'. So that's an added caveat to consider when contemplating a change to the UID 0 user's username. There will be problems, perhaps obscure and hard to track down, if a random piece of software tries to getpwnam('root').
One approach to take is to set root's password to some ugly random string. Save it in a locked file cabinet somewhere and use sudo to do all your root work. It makes it tough for password guessing attacks if the password is random garbage. As others have noted, it won't protect you from all, or even most attacks that try to break root, but it's one step that can be taken along with others to improve security.
Not all programs are smart enough to follow uid=0, some foolishly refer to the "sooperuser" as "root".
Standard Modu Operandi on a winbloze box is to rename the account called "Administrator" to someting else and create a a user called "Administrator" with no privs.
For the same reason it is reasonable to do this in a unix machine, however:
1. some programs that you want to work might not be built smart and may follow the user "called" "root" rather than uid=0.
2. unix hackers are smarted and more often than not follow uid=0 so it's not as effective to rename root.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.