Yosemite disable single user mode without a firmware password

[roiegat]

So were going through some testing on our macs and discovered that an individual (who doesn't have admin rights) can go into single user mode and esclate their permissions to admin. So the simple question is how do we disable a user from being able to go into single user mode.

Searching on the web it referred to a /etc/rc.boot file. I don't see that file in our current build (10.10.1 and 10.10.3). I do see rc.comm, rc.imagin, and rc.netboot. So which one should I edit to disable single user mode, and more specifically - how. Is this the right file to edit, or is there another file?

I'd like to avoid using a firmware password if possible at first to make life easier for users. What are you guys out there doing?

[mm2270 · Accepted solution]

@roiegat You don't need to enable Firmware passwords in a way that would prevent users from booting up, There are two modes for Firmware Passwords, Full and Command. Full is what you're describing where they would need to enter it every time they boot. We don't do this, and I don't think most environments do unless there are some very stringent security requirements that would call for that. The Command mode is only invoked when they hold down a boot modifier key, like "S", "Option", "R", etc.

[donmontalvo]

Not using Firmware password will only make life easier for users who are trying to do what you don't want them to do. :)

[mm2270]

@jacob_salmela posted a process he's using a while back that sends him alerts when users boot into Single User Mode, but it involves getting a number of elements installed and set up. It may be something to look at if you just want to be aware when users boot into it.
You can also set up an Extension Attribute that would gather local or AD accounts that have admin rights, then set up a Smart Group to collect Macs that fall into the 'danger' zone and have the JSS auto send you an email so you can be alerted when it sees an account with admin rights that it should not have. You can find an EA I wrote for that here

OTOH, if you really want to disable SUM, there may be a way using rc.server. That file does not exist by default on the regular OS X version, but I think gets created when you install OS X Server on a Mac. I have not looked into any solutions using it, but my guess is, you'd need to create an rc.server file and make a script out of it, and have it do something to disable single user mode access. Again, not sure on exactly how since I've not looked into it at all.

[jacob_salmela]

Here is that process. It doesn't work on Yosemite yet, however.

I used it in my environment since we weren't using firmware passwords, but I still wanted some defense from students messing around.

[roiegat]

@donmontalvo Adding another password to the mix wouldn't really stop them either. If they can unlock the firmware they can get into the single user mode. They would need to know the firmware password to log into there machines...so if I understand it correctly, it would just be annonying more people - which might actually cause them to want to do something bad.

@mm2270 We are going to have a admin right check in place, but ideally we'd like to prevent it from ever happening.

[donmontalvo]

@roiegat wrote:

They would need to know the firmware password to log into there machines

...only if they are trying to boot into Single User Mode, or boot from an alternate volume, etc.

[roiegat]

@jacob_salmela Thanks...will take a look. My wife is a teacher and some of the stuff the kids do these days on machines is so bizzare. Although I've seen my fair share.

So lets take a little break for a humor moment. This goes back to my help desk days about a decade and a half ago. Lady would call monday morning saying her computer is not booting up. Can't do much over the phone, so I send out desk side. They re-image the machine and every thing is good. This happens every monday for a month. I start to get curious and the next monday I go with the desk side guy to take a look. Machine would boot into linux and run a server which is odd since we were running Windows XP at the time. So we start asking questions. Turns out her son would take her machine on the weekends (which is against corperate policy), image it with linux, and set up an Unreal tournament server for him and his friends. Not sure how she kept her job after that....but you gotta watch out for kids with lots of spare time.

[roiegat]

@donmontalvo So if they don't know it they could still log into their FileVault encrypted machine as usual? If that's the case then firmware might work out after all.

[mm2270 · Accepted solution]

@roiegat You don't need to enable Firmware passwords in a way that would prevent users from booting up, There are two modes for Firmware Passwords, Full and Command. Full is what you're describing where they would need to enter it every time they boot. We don't do this, and I don't think most environments do unless there are some very stringent security requirements that would call for that. The Command mode is only invoked when they hold down a boot modifier key, like "S", "Option", "R", etc.

[donmontalvo · Accepted solution]

@roiegat wrote:

@donmontalvo So if they don't know it they could still log into their FileVault encrypted machine as usual? If that's the case then firmware might work out after all.

Correct. ;)

[roiegat]

@mm2270 and @donmontalvo Thanks for the info....I guess the last time I messed with firmware (around 5 years ago) it was pretty much full. So having the command options looks good.

[donmontalvo]

@roiegat Anytime, hopefully we'll see you at JNUC2015. :)