In Linux and other UNIX-like computer operating systems, the root account is the administrator account. A user with root privileges can perform many tasks that a standard user account cannot. In current editions of Fedora 17, the idea of a disabled root account is a foreign one.
But come Fedora 18, the next stable release, the root account will be disabled by default. It is one of the many new features of Anaconda, the Fedora system installation program. That at least is what you see in the just released Fedora 18 Alpha.
In this screen shot, which from the main interface of Anaconda, you can see below the ROOT PASSWORD button, though not readily legible, a 4-word phrase that says, root account is disabled.
Clicking on the root account button in the previous image automatically enables it, provided you specify the password.
With the root account disabled, the user created during the installation process is assigned to the Administrators group by default. This, of course, gives this user all admin privileges.
For visitors looking to get a site online this web hosting review site provides reviews of cheap, reliable hosting companies all of which operate in a Linux environment.
The thing that I do not understand is, why is it even necessary to disable the root account? Is there any disadvantage to having a system with the traditional root account enabled? I cannot think of any reasonable one, can you?
My opinion is that if you are running Linux you are, should be, a more knowledgeable user. And as long as I can reverse this, who cares.
But who here deploys Fedora in a production environment? RHEL yes, but not Fedora. It’s has always been (until now) supposed to be a developmental, bleeding-edge, distro.
Fedora team… stop trying to be Ubuntu, they just want to be M$ anyway. You are WAY better than that.
Same behaviour as Ubuntu. I ALWAYS set a root password for Ubuntu after the install:
$ sudo passwd
From the admin account.
Wow, the large amount of “the sky is falling” comments here is almost shocking.
@Adam Williamson
You are so on the money, it is ridiculously easy. Many here just simply do not know any better. Also, thanks for the help you have provided to all of us in the Fedora community and before that in the Mandrake/Mandriva community!
@The ones complaining about no root login…
I have been a Linux system admin in production environments for over 12 years. I can tell you that there is not 1 single box that goes in any production system I have worked on without sudo set up and root logins disabled. It has been that way for many years now and believe me when I say your banks and stores are ALL set up this way. PCI/SOX demands it if they accept credit cards or deal in sensitive data of any kind.
Not only is it more secure, it protects admins and users from themselves! By defining proper sudo rules for certain non-admin users and carefully creating acl’s you can avoid mistakes like typos by root and worse!
Let me shed some light on this for those here with a painfully obvious lack of knowledge.
1. Sudo by default is not passwordless, it requires the users password. You have to change the sudoers file to make it passwordless.
2. Using sudo means you have MORE of an audit trail to see who did what (if the logs say user root ran x command, who was logged in as root? Sudo tells what user ran sudo!)
3. ANYONE that uses vi/vim/nano/emacs to edit /etc/sudoers should log out and go read a book first. The “visudo” command opens the sudoers file using your editor but does checks before closing the file and WARNS YOU WHEN YOU GOOFED! If there is a mistake, it will not close the file until you correct it.
4. Sudo is PCI/SOX (security auditing) compliant while enabling root logins is forbidden by PCI/SOX… because large security firms KNOW that sudo is more secure!
5. Using sudo is NOT the same as as Windows security (or lack of). Sudo is far superior for auditing and restrictions based on any number of user defined rules/users/groups. Windows does not make this as simple (or even possible in some cases) to configure, manage, or secure.
6. There is nothing you can do as root user that you cannot do with sudo!!!! Prove me wrong, show me any command and I will recant that statement if you can stump me. I have used sudo ONLY for years now on thousands of servers so it will be hard to find something that I have not.
I could continue on for a while but it is pointless because the truth is, if you really tried to *properly* use or understand sudo you would know all this. In stead you are more concerned with attacking it with baseless hype. Still for your own reputations, you should consider how you discredit your selves so quickly with those that do know better. I can tell you this, you would never get hired by any large corporation if you spouted this FUD in an interview. They would thank you for your time and show you to the door, trying very hard not to laugh at you the whole way out.
Oh yeah and my favorite comment here… “idiocy!” Thank you Rubin for warning us of your intent to show us some.
Let’s look at the idiocy shall we?
>>> “no wait, I can’t, sudo don’t work”
– Only if you broke it, it works fine out of the box.
>>> “I think I should use a different distro….been there done that and changed distros”
– Break it and run huh?
>>> “Everytime this happens I wind up running puppy a little longer…kinda insecure but at least its functional.”
So you prefer insecure & functional over secure & functional?
Yep, Rubin… you nailed it! Idiocy at it’s finest lol
Thanks for the laughs people, it’s been fun.
Sudo is a pain. When using ubuntu, I always just do “sudo -s”. Anyway, your arguments only apply to niche systems, not to general purpose machines. Don’t know if you realize, but not everyone has a sysadmin to set the special rules and groups you describe, so the security you say sudo grants won’t be seen by any regular user.
I’ve never used Fedora (neither do I see a point in doing so), but if it is a general purpose OS (and the fact that there is a paid-for Red Hat alternative, indicates it is), then exchanging sudo for su is useless and will only make the system more cumbersome for intermediate-level users…
“Anyway, your arguments only apply to niche systems, not to general purpose machines.”
Security always applies, your mindset is what home users are hacked every day.
Sure, my PCI/SOX arguments may suggest enterprise level usage, but that was only to enlighten users and strengthen my position that it is more secure.
“exchanging sudo for su is useless and will only make the system more cumbersome for intermediate-level users”
How?
Please back that up with proof that it is more cumbersome. I would like to see any examples you have.
Here are some example usages that prove that statement wrong. Consider them and respond please.
Example with sudo:
sudo mycommand
{enter password at prompt}
Example with root login:
su –
{enter password at prompt}
mycommand
exit
More key strokes, and it is more cumbersome to log into root first then run your command and now log out of root.
With sudo you do not log have to log out. It was never actually logged in, just given root privileges temporarily.
Also, if you MUST run multiple commands as root, what stops anyone from running “sudo su -” and becoming root?
The password is disabled, which means you cannot log in by using the ROOT password. Sudo does not require you to use the root password… you use your own. Therefor you can still actually log in as root using “sudo su -“.
>Security always applies, your mindset is what home users are hacked every day.
I didn’t say that security doesnt matter, I said that sudo does not provide a more secure system to a regular user.
>Provide examples
Ok. So here goes my personal usage example:
I open a terminal to update my system (I dislike graphical package-managers) I do “Sudo apt-get update && sudo apt-get upgrade” and enter my password (btw, Arch is much better “sudo pacman -Syu”). I then go browser around the web while the downloading goes on. Around 30 minutes latter, I remember I wanted to install foo app, but I have already lost privilege elevation. I have to go again “sudo apt-get install foo-app” and enter my password AGAIN. Now, granted, it’s not that big of a deal, but since not much is going to be gained by not having a root password, then it’s just unnecessary.
I’d also like to point out at a many times argued point, which always seems to get ignored: for regular users, the valuable data is in /home/$USER, so the whole don’t-login-as-root is mostly pointless. Besides, what, do you believe people will just go around doing “rm -Rf /” as root? Please do provide some examples of things a regular user might do that sudo will protect them from.
Actually it does proved a more secure system to a regular user. Nobody can hack/crack the root password because it is disabled!
As to your example, that again is a use case problem. You could always just use “sudo su -” and run as many root commands as you want as root then log out. The root account is not truly disabled… just using a password to log into it. Also, when you get used to using sudo, you will start learning better habits. Like trying not to forget package foo when doing an install 😉
To your last argument, I think what you SHOULD have said was “for reguular users, they *mistakenly think* the only valuable data is in “/home/$USER”. In actuality valuable data can be in many places on you computer depending on what saoftware you run.
Users don’t intend to do “rn -rf /” typically but let me quickly show you how easy it is to mistakenly do just that command.
[root@host ~] ls
Desktop
Downloads
Documents
Pictures
test
[root@host ~] cd tmp
[root@host ~] rm -rf /*
The user missed the “.” and hit enter before catching it, it should have been “rm -rf ./*”. A simple typo and now as root you would have no OS and ALL users data s gone!
As for my example of how sudo could save you from that…
With sudo, you can define something this:
Cmnd_Alias DELETE_ROOT = rm -rf /, rm -rf /*, rm -rf /.*
%wheel ALL = ALL, !DELETE_ROOT
You would have been saved by that by sudo.
oops speaking of typo lol
meant to type “test” not “tmp”
[root@host ~] cd test
example is valid though as long as you don’t cd tmp lol.
“PCI/SOX demands it if they accept credit cards or deal in sensitive data of any kind”
Yes, just make up your own “facts” to support your position. That’s what the internet if for, right?
Excuse me? What fact did I make up?
I deal with PCI, SOX, and HIPPA compliance on a daily basis. Sudo meets the “2 step authentication” guidelines where direct login to root does not. This is because of the nature of PAM requiring your password for you to log into the system as a user, then sudo requiring your password to gain root privileges. The second base it covers in compliance is audit trails. You have audits and they review the audit trails for root logins and nessus scans quarterly and annually.
If you prefer I can show the compliance sections regarding “2 step authentication and audit trails.
> With the root account disabled, the user created during the installation process is assigned to the Administrators group by default. This, of course, gives this user all admin privileges.
This, of course, now brings the windows insecurity system to linux. The whole idea of having a root account with admin. privs., and regular users without admin. privs. is so that the regular users can not muck with the system configuration and break things for everyone else. By running the regular user with admin. privs., we gain the windows insecurity system where a single click on a proper web-page makes one’s windows system part of a huge bot-net, all without one knowing.
How exactly do you lose that by using sudo?
Sudo by default allows members of the wheel group to use sudo.
Did you even READ the quote you added at the top of your own comment?
I will say it again so that it sinks in…
The only user that gets in the wheel group by default is the user added during install!!!
Presumably you are doing the install and you setup yourself as the first user. This make YOU the ONLY admin that can use sudo.
Do you go and make EVERY user a member of the wheel group?
I hope not.
Then you go on to share that you believe that using sudo access makes you capable of being hacked by a malicious web site to the point of being a bot-net.
How does sudo allow this exactly when you did not even use it to open your browser?
Next you will tell us that sudo caused you to run off the road while driving drunk. Why not? You didn’t use sudo to drink the beer or start the car, so it makes just as much sense as your previous remark lol.
As David says, that’s not how it works. Any admin action requires authentication, either via sudo or PolicyKit.
idiocy! Ok, so I cannot log in to root and in some instances that means that the only way to set the clock is the command line….no wait, I can’t, sudo don’t work, and root is not available gksu is missing… I think I should use a different distro….been there done that and changed distros. Everytime this happens I wind up running puppy a little longer…kinda insecure but at least its functional.
…only way to set the clock is the command line? Sir, which distro do you use?
In the terminal mode, I often need root password in order to run yum or to do functions such as chmod, mount, tar etc.
When we say the password is blocked, or locked, do we mean for both terminal mode and for GUI interface?
I find that blocking root access via the GUI is creating a dangerous situation, vis a vis only allowing root access via command line.
In root with the command line mode rm or mv or many other commands have no “whoops. Once, my finger slipped on the keyboard with a rm xxx” and unfortunately a * was at the end of the string and I lost the system.
Many times I do a mv or cp of files from one directory to another. The mv/cp has to be done via a secure logon. Here again, with a slip of the finger, the wrong directory is chosen.
Next, I often need to run tar, and I have not found a gui version that allows creating compressed tar files
The gui interface for logon root is essential. Using drag and drop, or mark and copy or mark and delete, or even creating folders is a ever so much safer way of doing things than via command line.
With Fedora, I edit the appropriate files in /etc/pam.d to ensure I have a gui root logon. My take is that the root password is known by me alone, as I did the installation. I do not share root or give sudo to anyone else (I am in a small group of users).
In a 24/7 operation, root password would have to be shared. Still, it would be restricted. I did this by keeping it in an envelope in a safe place. I would vpn in to do any emergency maintenance.
I use root to create and maintain my crontab files.
And you really think your finger wouldn’t have slipped with:
sudo rm xxx
?
In Ubuntu, it’s simple enough to do sudo -i, which is essentially the same as logging in as root. Nothing wrong with sudo, and nothing wrong with what Fedora’s doing, so long as the functionality is preserved.
That’s the point I’ve been harping on. If sudo -i or sudo whatever gives you root privileges, why disable root passwd to begin with? What problem did it solve?
simple: if 3 people share admin priviliges, having a root password means that the password is shared. if you ever want to chage the root password you have to talk to all 3 people.
if one of those is working from remote you are stuck finding a secure method to share the password.
with sudo everyone gets to use their own password, and no shared root password is needed.
that’s one problem being solved.
greetings, eMBee.
Partially correct eMBee.
That is *one* problem being solved. There are also others being solved by this as well.
1. Shared password.
2. No way to ssh in and brute force the root accoutn password
3. Audit trails (user accountability)
4. Enforces NOT running as root
5. Added security on restrictions (sudoers rules)
and more… 😉
Bad idea in so many ways. Linux is not and can not be Plan 9.
If the account is disabled and you still allow sudo that means you have passwordless access and hence that user has full rights. Bad, bad and oh yeah, bad. Especially if they have no SELinux policy to cover it and Apparmour is incapable of covering such a thing.
Secondly imagine ‘sudo -u root vi /etc/sudoers’, or visudo, or su, etc, etc and you goof. Good luck… Reboot and “recovery mode” time for the majority of people.
Implementation of this methodology is pointless. It doesnt help average users in any fashion, it doesnt make ths system easier, it introduces break vectors in nasty ways and it also potentially makes the system less secure.
Good news is not only do you have a choice not to use any of these distros (I happen to use Fedora and have before fedora existed.) but additionally you can always change it and I for one will.
If they go this route it is simply because they, like ubuntu, are trying to mimic systems like windows and osx and in doing so are putting users, and us all, at risk.
“If the account is disabled and you still allow sudo that means you have passwordless access”
No, it doesn’t. sudo requires the user to enter their own password.
@Ericg
Actually, an account is disabled when the password in “/etc/shadow” has a “!” inserted at the beginning. That is what the commands “passwd -l” and “usermod -L ” do (see man passwd and man usermod). It will lock the account so that no login is permitted for the user. However, the command “sudo su -” still works. You can still switch user to root because you are not having to authenticate with the password.
Another method would be to manually change the entire password hash to a “!” or a “*”. Then you would have to use “passwd” to set a new password though. I use the tools provided so this is not my first choice. 😉
Also, as to the “sudo cd” issue… what’s wrong with “sudo su -” followed by “cd /some/root/owned/path”?
hmm my commands were killed by formatting…
make that:
“passwd -l username”
“usermod -L username”
finid: you can enable the root account on Ubuntu with a single command – ‘sudo passwd’. Set a password for the account and you’re done.
Given that it’s ridiculously easy to enable the root account if you want to, even if you don’t do so during install, this seems like a minor thing to me, for both Fedora and Ubuntu. You want a root account, you can have one. It’s not hard.
Yeah, it’s not that I did not know how to enable root’s passwd, it’s a question of, what’s the point of disabling it in the first place?
And if you really want to use the root account for system-wide tasks exclusively, you will not only have to enable the root passwd, but then change the account type of the user created during installation to Standard, from Administrator.
But that still does not answer this question: What advantage did switching to sudo bring to Ubuntu?
The point is improved security, audit trails, and user accountability. You should not log in or even su to root. If you have more than one user your logs simply show that root ran a command or worse, they show nothing. With sudo you have a complete audit trail in /var/log/secure.
Example:
Sep 18 23:12:13 XXXXXX sudo: myusername : TTY=pts/1 ; PWD=/home/myusername ; USER=root ; COMMAND=/bin/yum update
As you can see I now know that user “myusername” has run the command “yum update” at 23:12:13 on Sept 18th.
This is my audit trail. If I am missing root owned files, and I have sudo I can see who deleted them and when. When a user is logged in as root, you have no such audit trail. You will not even see an entry saying root deleted some files!
Another example would be that with SSH server running, a would be hacker will try to hack into the root account because it is always there. They just need to guess the password. If root is disabled they now have to guess a user name AND a password. They get NO feed back saying the user exist if they fail. It simply looks like a wrong password. They spend valuable time trying to get the pasword for a user that does not exist! This sends a special error to the logs which (if using host intrusion detection) will get caught and the admin will get notified and there IP will get blocked!
That is just some of the “advantages” you gain.
I don’t actually know, to be honest. It wasn’t really mentioned as a feature of the new anaconda design, it just happened. I just don’t see it as a big deal.
Ubuntu still has a root account. You just have to set up a password.
Doesn’t that counter Ericg comment?
Some Linux distros ask for a root password on installation, but root login is disabled by default in the GUI (KDE, etc…). Root login can be enabled easily(Google is your friend), but knowing the root password is usually enough to do anything most users will ever need to do on their own system. Some may never even need the root password…
Before Ubuntu came along and made sudo its default, every distribution asked for a root password during installation. Some good ones still do.
Its because its guaranteed to exist. One of the reasons you disable Root-over-SSH is because the attacker doesnt have to guess the name of the administrator account. Its root. Every unix has root. If you attack a system and you dont know a username, first you have to guess or find a valid username. Then you have to do a password attack. But if you KNOW the root account is a valid account then you only have to worry about a password attack.
I’m all for this, the only time I ever su to root on Fedora is for a FEW directories that a “sudo cd” returns Access Denied when im editting config files. If they can make those directories respect sudo as true root then ive got zero problem with disabling root by default.
Besides “Disabling Root” normally just means that its password is a random hash. (not the password IS hashed, all passwords are. But that the password itself IS A hash.) Its not like the account doesnt exist, it just doesnt have a known-password and that can be fixed by doing “sudo passwd root” from the user account and setting a new password if you DO need to get into the root account for some reason.
Even if it’s guaranteed to exist, what’s the difference if only SSH-key auth is enabled?
In that case no difference, but that’s not the default configuration.
That only covers SSH login, not PAM login. The difference is security for local logins as well.
Please understand, sudo is easier to use and far more secure. It carries with it an audit trail to show exactly who did what and when. It allows or disallows exactly WHO can have root privileges and on what criteria they can use root privileges.
When logging in as root locally you are root… period! With sudo, rules can be defined to a granular level to see what you can do as root.
Example:
## Allows members of the reboot group to reboot this system
%reboot localhost=/sbin/shutdown -r now
Now any user you have added to the reboot group (user created group) can use sudo to shut down the system but NOTHING else. They would not be able to run “sudo yum update” because you did not give them that access.
sudo reaches far beyond remote (ssh) logins as root. Disabling the root account just happens to have an added bonus of also removing the ability for a remote user to brute force your root account. It is not the sole reason though.
can i think of a reason? no, i run debian. but i will notice that this installer thing looks like it was designed by the backside of a drunken monkey. why is the text not legible??
It looks like the screenshots were taken running from the KDE live image – the default KDE theme doesn’t work terribly well with the newUI text colors. We’ll sort that out before Beta probably. It looks fine run from GNOME or from the DVD / network install.
Mimic Mac OSX.
after having signed their bootloader, kernel and modules by M$, next step will be to require every sys admin to be certified by NSA/CIA !
At least they still give you the option to enable it. Hope they don’t go the way of Ubuntu.
Is there any disadvantage to having a system with the traditional root account enabled?
Make it like a Ubuntu Clone, where every damn thing is a sudo 😀
That one reason I don’t touch Ubuntu.