somebody please help me here...
Ok.. so you can change the root account to a different name with a Linux box... for security or whatever reason... I also have a Mac OS workstation.. and I wonder if I can change the root name to whatever... so I ask in a forum... All of a sudden I'm a complete idiot for even asking... I get nothing but a bunch of off topic posts from people, who quote: "have been unix admin for years" and are now saying what a stupid idea... Hey, I'm just asking is it possible... what do you care? here's the post:
http://forums.macnn.com/showthread.p...hreadid=160799 Coming from a Linux standpoint I don't think this was a stupid question... So what if I want to change it? Heck, maybe I want to change it just because I don't want root as the user name... maybe my real name... who cares? No reason to call me an idiot just answer a yes/no question... All of a sudden Mac OS X is unix and everybody with a one button mouse is an experienced unix adimn... somebody please shoot me. Turns out that the root account is by default turned off... yeah I know this... but I still like to enable it sometimes do my thing, and then disable it... Then I get, "No other unix os will let you disable the root account" What's true here... please excuse my lowly mainframe admin standpoint.. I need support! |
Well like unSpawn pointed out renaming root is security through obscurity, which is not real security. Poorly written software doesn't do a check for uid(0) it checks by name (rare but still around such software).
But if you understand the possible risk of it you need to change /etc/password, /etc/shadow and /ec/group ... don't cry if this messes up your system. You have been warned! |
Quote:
|
I think we handled this question well in the other thread and if you take the 90 percent air out of the the macnn thread, you'll see their reach the same conclusion.
Again, if you want to really "protect" root uid, it would be more efficient to focus on taking away capabilities from root directly or tru using something like LIDS. So, if you still want to pursue this course, I hope you agree it's time to give us the ultimate overruling arguments and examples (and let they make a strong case, not something easily rejected) in favour of this approach. |
Quote:
Further they go on to say you can log into root shell from admin using sudo -sh... my point here is Look where your user base is coming from! A gui only OS... MAC OS 9... and if you can enable root this easy though the gui, what do you think 99% of these people are going to learn and do first? And do you think they will think to disable it? No more than likely, they will think its "Cool" because they now have neat little root account to use! (What's even worse, you can dual boot between OS X and OS 9... and when you boot into OS 9 you can modify ANY OS X file on the hard drive with no way to stop it!) so this *idea* of if you don't enable root, you don't have any worries, is TOTAL and COMPLETE bullshizzey.... |
Quote:
You should really check the case again: Do you want to SECURE your system or do you just want to rename root for fun? |
Quote:
Also patch your kernel using the grsecurity kernel patches or LIDS or some others. If you want a HIGHLY SECURE system go for OpenBSD |
yes
Quote:
Oh.. not mention all my systems are audited by www.edgos.com ...with no secuity holes... ever... |
In most basic terms the argument is that there is absolutely no reason to log in as root *ever*. All administration can be done from sudo commands. Therefore, there is no reason to even enable the root account.
There is a distinct difference between renaming, altering (or should I say corrupting?) account info and restricting logins. We already gave reasons why renaming the user name wouldn't add any (substantial) protection. Anyway. If I focus strictly on the act of denying login, not the value of doing so, yada yada yada, what could break a root login could be: "nologin" shell in /etc/passwd, chage and lock the account, ulimiting (maxlogins), PAM ACL, other PAM lib (like Xad?), emptying securetty, setting "exit 1" in the root shell's login script. Be warned tho things goin fubar trying out stuff is your fault, problem, responsability, not ours. Recapping this and the other thread I hope you agree the impact of disabling a root account has negligible value within the scope of any security framework because it IN NO WAY touches on the essence of what the root account represents: a set of privileged capabilities. Logging in may be viewed as unlocking a door to using those capabilities, but it is not the only door or the only way of unlocking. The fact you insist painting the door over with red paint instead of the sophisticated black it's always been doesn't take away stuff behind the door... |
Quote:
|
All times are GMT -5. The time now is 08:38 PM. |