In Mac OS X, the root account is disabled by default. The first user account created is added to the admin group and that user can use the sudo command to execute other commands as root. The conventional wisdom is that sudo is the most secure way to run root commands, but a closer look reveals a picture that is not so clear.
I’ve used all NT-series Windowses as Administrator for as long as I can remember. I’ve never been the victim of a local/remote hack, or virus/spyware infection. How do I do it? Conventional wisdom.
When I switched to OS X, I didn’t throw that conventional wisdom away. I don’t do away with all security-conscious thinking just because I’m using “God’s gift” as my operating system. The result of that is that I’ve enabled the root account for su’ing simply because I can faster work as root to do various things, and I have no discomforts about doing so.
All it comes down to is whether or not you’re an “intelligent” user. Most Macheads will go in a frenzy if you tell them you use root, but those same people will go in a frenzy when someone asks about HFS defragmentation programs, claiming that HFS+ doesn’t get fragmented. They can be ignored.
The same thing can be accomplished without enabling root by just typing sudo bash.
Then you have a root shell, and it would be as if you had enabled root. So there really isn’t even a reason to have the root user enabled.
And instead of having 2 user accounts that can execute commands as a super user, you only have one.
But as you said, it all comes down to how you use the account. I also never get infections on my Windows PC, and it comes from being more paranoid than average. I think that comes from being an Administrator.
And what difference is there between having a sudo bash shell or an su shell? The latter is more secure, because it requires the root password, which can be completely different from your password.
those same people will go in a frenzy when someone asks about HFS defragmentation programs, claiming that HFS+ doesn’t get fragmented
I might be mistaken, but I believe auto-defragmentation was added to Darwin a while ago (I think in Panther). Although this function only works with files up to a certain size, it should alleviate the need for defragmentation utilities.
AFAIK the HFS+ filesystem’s resistence to fragmentation is due to the robust allocation algorithm.
More generally how a first-fit filesystem as HFS+ works in that way: when asked to write to disk, seek for an adjacent disk portion anough wide to store the file.
However, when the free space is low the allocation algorithm cannot do miracles and files get fragmented if not enough contiguous free space is found (fragmented free space is generated delting files and is obviuosly used by the filesystem when the space is very low).
Overall, a good first-fit filesystem can resist to fragmentation very well unless the free space gets very low and unless the filesystem has frequent file deletion (i.e. it’s used for temporary files) so such filesystem usually don’t need to get defragmented by most user and in the worst cases the users simply put the data on another fs and then format the partition, then rewrite the data (that’s why on a well administered machine with an heavy workload the filesystems should be separed, one unit for the system, one for the data, one for temporary files etc…)
Cool idea. I might try it if it’s not patented. (I have issues with fragmentation on my operating system’s filesystem.) I had a similar issue with heap memory stuff and decided to use powers of two for large allocations, to standardize sizes. Would waste too much space with disks however.
AFAIK first-fit concept is widely used in filesystem since many years, and various algorithm used to accomplish it are quite classic topics in math.
I doubt that may exist serious patent issues about the first-fit idea and on most basic ways to build it, althougt may certainly exist patents or n.d.a. on some very specific high performance implementations (that may be pointless to implement in today’s desktop computing).
I mean, probably it’s possible to build a fairly decent first-fit filesystem (decent for anything below a supercomputer) with public domain notions, while i’m not certain that some non-trivial improvement may be done without hurting with some patent claims.
You are right, check this:
http://www.kernelthread.com/mac/apme/optimizations/#FIVE
It only does so when a few specific conditions are met. If the file is above the set size, it is not automatically defragmented, for instance.
So you think it’s conventional wisdom to run as root or administrator all the time? That’s gotta be about the worst advice I’ve ever heard. You say it never causes problems? Seems at the very least I remember you talking about your “friends” messing with your machine while you were in the bathroom. Would that have happened if you weren’t running as administrator? And even supposing your wild claim of never once having any sort of malware is true, you’d still be safer installing and running apps with a regular user account.
Sudo, I suppose I’d agree, it’s not very useful, unless you’re wanting to control what someone else can do as root, then it definitely has its uses.
You deliberately misunderstood my point.
I said that I su as root to do a few things (in the Terminal), because it’s faster. I never said I use my Mac as root.
I misunderstood nothing. I’m merely commenting that running Windows as an admin unnecessarily in my opinion is far from wise. I only mentioned running as root as that would be the unix equivalent.
As for enabling the root account on OSX and using that over sudo, I don’t have a problem with that. Like I said, to me sudo only seems useful when you want to limit what someone can and cannot do as root.
Speaking of running as an admin though, I’m curious, what type of account is your everyday OSX account? Normal or admin? Because if your answer is admin you’d be making the same mistake on OSX as you seem to be making on Windows.
I use an admin account on OS X too. However, the parallels that you draw aren’t entirely accurate.
I would rate the types of Windows/OS X accounts in the following fashion (when going by access capabilities):
OS X User
Windows User
OS X Administrator
Windows Administrator
UNIX root
My reasoning behind this is that an OS X admin is still prompted for the password to make any system-level changes, but is allowed to make them with the password. A Windows administrator can simply do 95% of things without being asked for a password. A UNIX root user can do *everything*, including drive the system into the ground at full speed. UNIX root is equivalent to Windows’ SYSTEM account, which is not an account that you can normally log in to and use.
Try accessing your SAM database, or deleting the registry files as Administrator. You can’t do it. You could as SYSTEM.
With sudo, you type every command that requires root privilege with “sudo command”. With a root shell, you only type “command”. The problem is “accident”. With a root shell, it is possible that you do some wrong thing that is unrecoverable by, e.g., mis-typing. That’s a danger of using root account that I think a lot of us experienced before. In my experience, if I explicitly use “sudo command”, I am effectively saying that “I know I am doing administrative work, I know I need precautions, I am not typing wrong commands and I know what I am doing”. Just in case you know you typed something wrong in the command after pressing enter, you still have a chance because sudo requires a password in order to run, not run immediately like the root shell.
Oddly enough, I make far more mistakes using sudo than not.
When I su, I do it for a purpose, and once I’m done, I exit.
When I sudo, I get tired of typing sudo on every line, so i just hit the up arrow key to repeat last line, and delete to the sudo, and type the new command. The issue is, when I’m working on something quickly, I get careless, sometimes I might leave part of the old command there. Or sometimes I accidently hit enter with the old line there (bad for a rm -rf * when you’ve changed dirs!) Etc. It just makes me really go out of my way to type that stupid “sudo” every time I want to run a command, so I’ve nearly brainwashed myself/my fingers into typing it with every command. I don’t even think about it anymore, it just appears. This causes mistakes
I guess it all depends on the person. I grew up with unix, and having a root shell is what I’m used to. I don’t screw around when I’m root, I do what I need to do, and then I logout. Most old salt sys admins would say the same thing. Sudo just seems like a bandaid to avoid people learning the hard way to be careful. Unfortunately, for most, it doesn’t add up to any more security/safety, and it doesn’t teach you any good habits. Thinking “oh, I have to type sudo, therefore I won’t make mistakes” == disaster waiting to happen.
This isn’t a flame btw, please don’t misunderstand me. Each person has their preferences, and I’m sure for some people sudo might be safer. It just doesn’t seem to be for the majority of the admins I’ve been around, nor for myself.
Your whole post is moot because you can always do sudo -i and get a root shell.
That doesn’t make my point moot, it just tells me that there is no advantage to sudo than there is to having root enabled. If you can open a root shell with sudo -i, you might as well just enable root and let people like myself get on with their work. Oh well, I use Solaris, this whole discussion is “moot” to me. Actually, by your method of thinking, 99% of life is moot.
sudo on a single-user system is a convenience, not really a necessity. Especially if your one user has full sudo access (can run any command).
sudo on a multi-user system where you only want certain individuals to be able to run certain commands, is a blessing. visudo and the sudoers file, when properly configured, can make administration of a box by mutiple people so much less complicated.
Have a junior admin that doesn’t really know what they are doing, and you only want them to execute commands X Y and Z? Configure sudoers to only give them access to those commands.
And every command run by sudo is logged, so you always know who broke what and when. Compared to su or a root login where you only know who was logged in, and not what they did.
ACLs were invented for a reason. Obviously root/sudo/whatever is not fine-grained enough for all purposes. ACLs fix this.
“And every command run by sudo is logged, so you always know who broke what and when. Compared to su or a root login where you only know who was logged in, and not what they did.”
Judging from the installs I’ve seen, this makes no difference. On all stock installs of all OS’s I’ve tried, executing a command using sudo is no diff than executing a command as root. This includes rm -f’ing logs, or linking them to /dev/null, or whatever crazy fun people want to have.
I’d say the best policy is hiring people worth a salt, not guys who have 20 years of experience in win2003 and 500 years of SQL experience and 78000 years of linux experience. Seriously, have you seen monster lately? Damn. Hire people who actually know what they are doing, not people who know how to fill their resume with bullshit that looks impressive. I’ve got 20-someodds working for me (i’m 20-somodd myself!) who I’ve never had any problem from. With root access. What’s better, I actually keep backups. Whatever they *could* screw up, I can fix in 5 minutes time. Amazing what good system administration/management/employees are capable of.
– Commands executed in a root shell aquired with sudo -s are logged to the users shell history file. Besides, if someone has gained root on your box you’ve got bigger problems than “what commands did they execute”. You might as well wipe the box clean.
– If you think someone can guess your user password and then gain root with sudo, the solution isn’t to enable root. The solution is to pick a better password and change it often.
I still haven’t heard one good reason for enabling the root user.
– Commands executed in a root shell aquired with sudo -s are logged to the users shell history file. Besides, if someone has gained root on your box you’ve got bigger problems than “what commands did they execute”. You might as well wipe the box clean.
and root are logged to root history file. Besides if someone were to gain root access? It is easier to gain sudo access than su (or at least equaly hard). And if it gains sudo, enabling root is just one command away.
no diff here.
– If you think someone can guess your user password and then gain root with sudo, the solution isn’t to enable root. The solution is to pick a better password and change it often.
Nope, often changing doesn’t help here, if you think it does then you’re naive. One way to do it on *X is brute force attack. No system provides trigger that would start screaming when too many false logons would suddenly spawn. But the good thing is that on *X trigger is usualy 10 lines of scripts away (and log redirection).
Just one page that describes what can people find on net. Just google for “password cracking methods”
http://www.password-crackers.com/en/articles/12/
I still haven’t heard one good reason for enabling the root user.
With allowed sudo, there is no value to enable root. Except if one preffers it that way. Disabling sudo and enabling root is the only sensible thing to do if you preffer working with root instad sudo way.
I still haven’t heard one good reason for enabling the root user.
Word
I’ve been running OS X since 10.1 days and I’ve never needed to sudo or create a root account to do any vital task on my computers.
As the sysadmin, pretty much the only things I don’t own are the absoutely critical files that make the OS go.
Why on Earth would I want to go dinking around in those files anyway? It’s like handling radioactive material with an oven mitt — not a good idea.
The same goes with Ubuntu. Yes, I have to Sudo to install software but once again, outside of that, why do I want to be making changes to the mission critical files? I have no business there, and I’m greatful for a system that locks me or other users out of accidentally deleting the wrong folders.
except think of this. you have sshd. however, you also have permit root logins set to no. now, if a remote user wants root access, they need to compromise two accounts with two passwords to get there (regular user su -> root).
with sudo, your regular user will almost certainly be allowed remote logins, but now if the attacker has it’s password, it also has root via sudo…
personally there’s only one legitamite reason I could think of enabling sudo is in a multi admin situation where you want to delegate limited priviledges to certain folk.
other than that, it’s basically just a false security blanket, which personally I find annoying to use.
…Is he advocating root or sudo accounts? Or applying protections to the sudo account? Or enabling the root account? I was confused reading it. On the other hand I am sick, and my bedtime was an hour ago… so I am a bit unfocused.
…Is he advocating root or sudo accounts? Or applying protections to the sudo account? Or enabling the root account? I was confused reading it. On the other hand I am sick, and my bedtime was an hour ago… so I am a bit unfocused.
I think what the author is trying to say is, whether it is ROOT or SUDO… they are just tools. How safe and secure a tool is also depends on how the user utilise the tools.
The default settings my give one tool more advantage than the other tool in a particular situation, but not ALL situation.
I think his article is pointing out that the arguement of sudo being more secure in the default configuration is a bit fallacious.
He also pointed out that a poor choice of password for root (same as your user account) and so on would be no better.
Then he showed whether you use sudo or root, you could make either more secure than the default configuration. Basically he was avoiding a sudo/root flame war, while at the same time giving each side something useful to walk away with.
Actually su root is disabled on normal MacOSX and enabled on the OS X servers by default. Looks pretty reasonable to me.
Is that you can allow users to execute only some commands as superuser.
This is very useful to lock the machine at a higher level.
Then there is the old discussion about “should really users be allowed to run admin commands” but let’s assume the administrator of the box has good reasons to allow so
“is that you can allow users to execute only some commands as superuser.”
It’s also good for preventing you from making dumb and catastrophic mistakes like “rm -rf /” and such. Sure, it’s not fool proof and if you really wanted to you an circumvent it but it does catch unfortunate typos and mistakes.
Another reason NOT to use root on OS X:
If you are logged into the desktop as root, then you will not get notified when something wants root permissions, such as those nasty OS X trojans that are starting to pick up steam … so DONT DO IT.
Another reason NOT to use root on OS X:
If you are logged into the desktop as root, then you will not get notified when something wants root permissions, such as those nasty OS X trojans that are starting to pick up steam … so DONT DO IT.
I think people are talking about root shell you get with “su -“, not logging in desktop as user In this case you’ll still get prompted what you said.
But for the case you were saying. Yes, DON’T DO IT IT’S A BAD KARMA for your computer.
I’m the crazy guy who’s delusional thinking y’all might be talking about me. I have an operating system with a Root(“”) command which sends command text to a “root” task. This task is not intended as a security feature. All tasks have parents and the root task is just the parent of all. It stays in a server kinda mode where it handles requests from everybody. If you wish to make an application available to all tasks, you #include it as root using Root(“”) or right clicking on a directory link and selecting root_include. Then, all tasks can run the code because the name of functions in the root symbol table are inherited by all. “Root” was not a good choice name, since it creates such confusion.
1.) There’s no reason to enable the root account.
2.) You should be using a NON-admin account for your daily work.
3.) Your admin account, with sudo-capabilities, has all you need for “root”-work. Problem solved. At least if you use different passwords for the work and the admin user.
So long as you add the standard account into the sudoers list of accounts, this works just fine; with very little hassle.
Sometimes you want to see the system.log.
An interesting point I don’t think has been addressed so far is that enabling root re-enables a security issue that Apple has largely ignored. Any user with sufficient rights can execute “nidump passwd .” and get a dump of the password file, to the console. In earlier versions of OSX, *all* passwords were unshadowed when you did this, and their 8 char max length made this even more amusing, considering the sudo ALL essentially makes any admin user root. 10.3 started obfuscating user passwords here, which is a good thing, but neglected to shadow root’s password, which is a bad thing. There are easy ways to change this fact, but it really *should* be the default behavior of the box. I’m not sure if this is still an issue for 10.4 or not.
Admin previlage exploitation was windows teritory. Now MAC is also going to be the same way?
Sudo or root? average user who is running away from MS gets scared at the first bump of MAC. and the conflicting and overhelming suggestions on net and finally not finding correct answer weater MAC is more secure or not, average joe turns back to MS, knowing completly that it may be insecure system.
A known deep sea is better than unknown devil.
How feasible would it be to have the root user’s home directory (or something to that effect) on a USB drive and to be able to use sudo, you would have to have the drive plugged in and mounted? That way, when you are done, you dismount and unplug the drive. Then no more sudo by anyone trying to compromise the machine.
IANALG
I am not a Linux Guru.
Edited 2006-03-22 14:24
How feasible would it be to have the root user’s home directory (or something to that effect) on a USB drive and to be able to use sudo, you would have to have the drive plugged in and mounted? That way, when you are done, you dismount and unplug the drive. Then no more sudo by anyone trying to compromise the machine.
Feasible, yes. Effect, no. The only thing you would protect is your shell history (which you can delete on logoff if you desire that anyway) and some preferences files. But nothing effective. If mount point exists those files are just recreated as new on need.
IANALG
I am not a Linux Guru.
Then again, who is? Every day your knowledge gets smaller and smaller against the new things that exist. And every little subject you touch provides a new vast of possibilities.
I guess what I was trying to get at was have the root user’s credentials or something hosted on a USB drive such that root couldn’t log in unless that USB drive was mounted.
Sounds plausible & feasible to me. However, I think I just broke one of my own rules.
“It is better to be thought a fool than to open one’s mouth and remove all doubt.”
To an idiot, anything is plausible & feasible. Probably even reasonable.
IAAI
🙂
“It is better to be thought a fool than to open one’s mouth and remove all doubt.”
Yeah, but sometimes “fools” have to exist, so “geniuses” can get new ideas and interpret them differently. And there is a difference between one that knows he knows nothing about some topic and the one that doesn’t know anything about it but he still considers him self as knowitall. First one can only be wrong, while second is a fool.
“Fools” (like you called them) are not bound by usual restrictive mind (and more you know about one topic, the more you’re bound to its restrictions). Often they imagine something impossible, but very possible and usable if one can interpret another angle to the same solution. Although sometimes they say things that can simply be considered as foolish or plain wrong.
So… no, I don’t agree that one should call people speaking their mind a “fool”. Fool is terrily deserved for those spewing FUD and trolls without skill and imagination.
And while I’m speaking about this… Most of the inventions were made because people inventing them were lazy (one doesn’t want to walk so he invents a car), not because people wanted to invent something. But even if they invented from the second reason, inventors were just counting that lazy people will spend money on their invention.