- This topic has 10 replies, 6 voices, and was last updated 16 years ago by
Patrick Gallagher.
-
AuthorPosts
-
March 4, 2009 at 9:14 pm #375623knowmadParticipant
OK, another open ended question.
While writing my grand setup script it was pointed out to me that the setting of the root password and then disabling root was pointless in leopard.
I tested and low and behold, its true.
Any local admin can reset the root account password without knowing it, and can activate/deactivate root again without knowing any more than their own password.
So, aside from setting root to not be able to login, what do you do to control it?
I know, most say they don’t let their users in as admin. That is not an option for me.
I am wondering if maybe there is an access list for enabling/disabling and resetting the password of root. Sudo has such a list, but its built into the command, so I am not hopeful.March 4, 2009 at 9:21 pm #375624tecnobabbleParticipantI’d look in /etc/authorization… my guess it’s something you can set there.
March 4, 2009 at 9:51 pm #375625tecnobabbleParticipantsystem.services.directory.configure is the one you want; change the group to something other than admin, perhaps a group that your own admin account is a part of and nobody else? This will prevent anybody using from using the Directory Utility to mess with root. (or anything else for that matter)
My test group was named blueberry.
Of note, this does nothing to prevent an admin from authenticating against dsenableroot. That still works if your an admin.
March 4, 2009 at 9:51 pm #375626larkostParticipantIf you let users run as full admins, then they can do this. Trying to go back and plug the leaks so they can’t enable the root user at that point is going to be an exercise in frustration. You are better off going on of two other directions:
1) Accept that the users are admins on these computers, and deal with the fact that they can mess around with anything they want.
2) Do not grant the users full admin access, but rather create a group that has specific rights to do things such as installing software, and then twiddle with the sudoers file and /etc/authorization to provide them with these rights. Note: granting them permissions to install things means they can get creative and create their own packages to get root permissions. So this can only be seen as a bump, not an iron wall.
March 4, 2009 at 10:34 pm #375628knowmadParticipantLarkost,
Your right….. but….I don’t have the authority to set that rule, much though I would like to.
March 4, 2009 at 10:47 pm #375629larkostParticipantThen you are stuck with #1: Accept that the users are admins on these computers, and deal with the fact that they can mess around with anything they want.
Make sure that your management understands this, and that the management over both you and the end-users understands this as well. Then you have done everything you can reasonably do.
March 5, 2009 at 1:20 am #375636Rusty MyersParticipantI agree with Larkhost.
You just have to trust your users, no matter how many flaky users you have… I’m dealing with the same type of issues. Most of my users are admin, when they ask to be. I have to trust that they don’t change my admin password, disable ARD, install limewire, etc.
It happens, but it’s far and few between instances.
RustyMarch 5, 2009 at 3:43 am #375638knowmadParticipantoddly i am not worried so much about my end users, but their kids (it would work if it hadn’t been for those meddling kids)…
boyfriends/girlfriends, brothers cousins family and friends….
Its the well meaning people who decide to ‘fix’ things for them while they are away from the office…. ie people who know enough to enable root in the directory utility but not in the command line… essentially, those meddling kids
Those who are determined, they will find a whole, those who are not determined will give up if the obvious entries are locked.Larkost (et al) is correct, not handing out Admin rights would be ideal. But this place has a culture of entitlement, regardless of effect or outcome. So I do what I can.
March 9, 2009 at 5:19 pm #375656knowmadParticipant[QUOTE][u]Quote by: MacTroll[/u][p]Manage root as best as possible. However, I’d protect your rear by stashing an admin account in either a secondary local directory or some other obfuscation so you can always get back into the box.
At that point the root account is sacrificial and just serves to distract away from the admin account that you actually care about.
Even this is a hack at best and you’re just rearranging deck chairs though.[/p][/QUOTE]
but they are such lovely deck chairs, and put them in the right order and things look so nice….
Back to reality, security through obscurity ON ITS OWN is not good security. As part of a larger and more comprehensive whole, it has its place.
Hidden Admin account (both by sub-500 number AND by location): Check
Individualized password for admin/root account and master password specific to each machine: Check
Disabling root as much as possible: Check
Locked Single User Mode (apple suggests against it, but its useful): Check
Firmware Password: No, it gets in the way of too many things, so good idea though it is…. not for me.
Disabled Guest account (need to figure that one out better): Check
DIsabled File sharing: Check
Disabled internet sharing: Check
Bluetooth not discoverable by default: Check
Other nebulous security measures: Check (no coffee today, brain on fritz, cant think of what else we do).Open to new suggestions: Check…. what’s your favorite security measure that reduces ‘accidental’ or ‘well-meaning’ problems but maintains machine usefulness?
March 27, 2009 at 9:22 pm #375832Patrick GallagherParticipantI prevent root logins with:
[code]/usr/bin/dscl . -create /Users/root UserShell /usr/bin/false
[/code]This will stop most users from using root, at least those who don’t know how to check the shell that root is using. 😀
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed