Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > macOS > Tiger security, ummm...

Tiger security, ummm...
Thread Tools
Kvasir
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 08:20 PM
 
So boot Tiger in Single User mode, follow the on screen instructions to run:

sh /etc/rc

Are you happy with the result? I'm not.

Why does this OS enable a root exploit, with instructions, out of the box?

I've been in communication with Apple about this - their corporate response seems to be "enable OFW password".

BS! If you can sit at a machine to attempt to boot to SU mode in the first place, you are easily placed to defeat/bypass an OFW password (physical lock on the case or not - these are hardly diebold locks afterall). OFW is NOT a fix to this - a simple goole search tells you how to get around that..

Why does an OS, out of the box and by default, offer a trivial root exploit without authentication?

Editing ttys (as in Jag) has no affect, and since rc.boot is gone in Tiger, secureit is useless.

Just MO, but this is not good, and seems clearly regressive, not progressive (WinXP Pro is more secure then this, for crimenys sake).
     
nonhuman
Posting Junkie
Join Date: Jun 2001
Location: Baltimore, MD
Status: Offline
Reply With Quote
May 4, 2005, 08:26 PM
 
All OSs have easy root exploits when you have physical access to the box. If you are physically at the machine you can have your way with it no matter what OS it is running.
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 4, 2005, 08:34 PM
 
Originally Posted by nonhuman
All OSs have easy root exploits when you have physical access to the box. If you are physically at the machine you can have your way with it no matter what OS it is running.
Yep. Even if they disabled Single-User Mode, you could still just go in with a boot CD. Non-issue.

Anyway, if you're dealing with people who know enough to open up the case to defeat an Open Firmware password, you're also dealing with people capable of opening the case and taking your hard drive out.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
ashtoash
Dedicated MacNNer
Join Date: Dec 2004
Status: Offline
Reply With Quote
May 4, 2005, 08:35 PM
 
No with OpenFirmware you can require a password to boot off cd or any external disc/disk. Apple need to make this more secure. I thought it was kinda a joke.
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
May 4, 2005, 08:36 PM
 
Argh.

This is NOT a security risk or an exploit, period.

If you have physical access to the machine, you ARE essentially root, period.

This is true of ALL platforms, ALL OSes.

All OSes allow some form of local administrative access if you have physical access to the machine. In UNIX variants, it's "single user mode".

The solution to make quick root-level access difficult is to enable an Open Firmware password. This disables ALL modifier keys (e.g., target disk mode, booting from CD, Open Firmware without a password, drive selection via the option key without a password, single user mode, etc).

But, you can disable Open Firmware password protection by changing the physical amount of RAM in the machine, and zapping the PRAM.

So you lock the case.

But someone can cut the lock.

At this point, if you're still worried, they can also take the drive out of the machine, or set the machine on fire. Does that constitute a "security risk"? That's the nature of physical access. Once again, repeat after me:

On all platforms and all OSes, if you have physical access to the machine, all bets are off.

Your only recourse for data protection is encryption (which is what things like FileVault are for).

So, in short, you're completely wrong in your assessment of the situation. (No, really. You are. Trust me.) Apple's response was 100% appropriate.
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 08:37 PM
 
Originally Posted by nonhuman
All OSs have easy root exploits when you have physical access to the box. If you are physically at the machine you can have your way with it no matter what OS it is running.
No soap dude - I've been in IT for 20+ years. I'm fully aware of the adage "no security without physical security".

But an OS that includes a root exploit out-of-the-box, and advertises it at the boot screen - that's just wrong. Apple needs to fix this, and soon, since no public facility is going to install Tiger until it is.

Physical access to machines inherently carries risk (given, in an Univ or public school environment, but you take measures to secure against that, and accept the risk), an OS that openly supports it is not acceptable.
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
May 4, 2005, 08:39 PM
 
Originally Posted by ashtoash
No with OpenFirmware you can require a password to boot off cd or any external disc/disk. Apple need to make this more secure. I thought it was kinda a joke.
Um, no.

They don't need to make anything more secure. An Open Firmware password is a perfectly acceptable solution, and requires physically opening the machine and manipulating the physical amount of RAM in the computer to disable. An Open Firmware password disables ALL boot modifiers and will prevent any person from casually booting into, e.g., single user mode, or resetting passwords while booted from CD, etc.

This is akin to saying "Apple makes its computers far too light! Anyone can just walk into my office and steal it. And if I lock it down, they can still walk in with a bolt cutter and steal it! Apple needs to make this more secure!"

...
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 08:43 PM
 
Agreed, physically opening the machine to manipulate ROM is an unavoidable risk. Making the OS so anyone can boot a fully loaded OS as root is a mistake. That's what's wrong with Tiger.

As I said, I understand, public machine's carry risk - SU mode does not need to be wholly unsecured however, it can at least still require authentication by deafault.
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
May 4, 2005, 08:44 PM
 
Originally Posted by Kvasir
No soap dude - I've been in IT for 20+ years. I'm fully aware of the adage "no security without physical security".

But an OS that includes a root exploit out-of-the-box, and advertises it at the boot screen - that's just wrong. Apple needs to fix this, and soon, since no public facility is going to install Tiger until it is.

Physical access to machines inherently carries risk (given, in an Univ or public school environment, but you take measures to secure against that, and accept the risk), an OS that openly supports it is not acceptable.
Dude. You are already root in single user mode, whether there is any text to that effect or not. The text simply explains how to continue a boot of the machine via single user mode. But anyone in single user mode is already effectively root. You fail manifestly and ridiculously to understand the incorrect nature of your position. This is no more a "root exploit" than being able to physically walk away with the machine.

And you're also laughably wrong about "no public facility is going to install Tiger" because several large enterprise organizations, academic and otherwise, are in the process of Tiger deployments, with normal Mac OS X security best practices (e.g., an Open Firmware password and physically locked cases, preventing single user mode access). You should perhaps check into the Mac Enterprise public mailing list, and MacEnterprise.org. This issue has not come up once, because it is a complete non issue. The text will remain, and Apple will NOT change the behavior of single user mode, period. It is fundamental to the OS, and is equally fundamental to other *nix variants.

I'd almost say you're trolling.
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 08:50 PM
 
In Jag, a simple two character edit of ttys, forced admin password authentication when booting in ANY mode, other than the normal GUI login screen.

And I know for a fact that many large Universities in the NE corridor are delaying Tiger (not just for security issues, althoug that's explicit too - but also for software to catch up).

And I don't know who you talk to, but our developers are telling me that yes, admin password authentication is indeed coming to OS X, for any non-standard GUI login screen boot.

And most Linu\X/UNIX.BSD systems are either by default that regardless of runlevel, or easily made so, they reuquire authentication.
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
May 4, 2005, 08:52 PM
 
Originally Posted by Kvasir
Agreed, physically opening the machine to manipulate ROM is an unavoidable risk. Making the OS so anyone can boot a fully loaded OS as root is a mistake. That's what's wrong with Tiger.

As I said, I understand, public machine's carry risk - SU mode does not need to be wholly unsecured however, it can at least still require authentication by deafault.
Once again, you're incorrect. And now I know you're trolling.

Since Mac OS X 10.0.0, you have ALWAYS been able to:

- be root in single user mode by default
- start the necessary system resources for network connectivity
- boot a graphical OS

Why are you making a distinction between single user mode at a command prompt and "booting a fully loaded OS"? This has always been possible, and I fail to see the relevance or your point, considering:

1. You are ALREADY ROOT when you are in single user mode, and
2. Activating an Open Firmware password DISALLOWS ACCESS to single user mode, period
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
May 4, 2005, 08:55 PM
 
Originally Posted by Kvasir
In Jag, a simple two character edit of ttys, forced admin password authentication when booting in ANY mode, other than the normal GUI login screen.

And I know for a fact that many large Universities in the NE corridor are delaying Tiger (not just for security issues, althoug that's explicit too - but also for software to catch up).

And I don't know who you talk to, but our developers are telling me that yes, admin password authentication is indeed coming to OS X, for any non-standard GUI login screen boot.

And most Linu\X/UNIX.BSD systems are either by default that regardless of runlevel, or easily made so, they reuquire authentication.
So let me get this straight.

You're telling me that you think you're fundamentally more secure by activating a crypt hash for the root account (which is what the /etc/ttys modification requires, which essentially considers the console untrusted and was cruft from days of BSD long ago), instead of leaving it disabled and enabling a password on the boot firmware of the machine that disables ALL booting or boot modifiers except to the selected boot device?

You have got to be sh*tting me.
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
May 4, 2005, 08:56 PM
 
Security maxim #1: Boot access is root access.

If someone has physical access to your machine, you are screwed. If nothing else they can steal the hard drive, take it home, and scrape the contents at their leisure.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
ManOfSteal
Addicted to MacNN
Join Date: Aug 2004
Location: Outfield - #24
Status: Offline
Reply With Quote
May 4, 2005, 08:58 PM
 
I like this thread.
     
nonhuman
Posting Junkie
Join Date: Jun 2001
Location: Baltimore, MD
Status: Offline
Reply With Quote
May 4, 2005, 09:02 PM
 
Originally Posted by Kvasir
No soap dude - I've been in IT for 20+ years. I'm fully aware of the adage "no security without physical security".

But an OS that includes a root exploit out-of-the-box, and advertises it at the boot screen - that's just wrong. Apple needs to fix this, and soon, since no public facility is going to install Tiger until it is.

Physical access to machines inherently carries risk (given, in an Univ or public school environment, but you take measures to secure against that, and accept the risk), an OS that openly supports it is not acceptable.
How does it advertise it at the boot screen? That's only if you've already booted into single user mode, at which point you're already root and probably know what to do with it.

As others have pointed out the OF password is adequate security if you're worried about this. It will prevent people from booting into single user mode or from another drive. You've got bigger problems than root exploits if your users are cutting the locks on your cases and messing with the innards of your computer.

Plenty of public facilities installed Windows even though it has a default administrator login that's a hell of a lot more user-friendly than single user mode. I don't see this causing any problems for Tiger.
     
ManOfSteal
Addicted to MacNN
Join Date: Aug 2004
Location: Outfield - #24
Status: Offline
Reply With Quote
May 4, 2005, 09:06 PM
 
piracy vs. Kvasir

Somebody just lost....badly.
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 09:11 PM
 
Originally Posted by piracy
So let me get this straight.

You're telling me that you think you're fundamentally more secure by activating a crypt hash for the root account (which is what the /etc/ttys modification requires, which essentially considers the console untrusted and was cruft from days of BSD long ago), instead of leaving it disabled and enabling a password on the boot firmware of the machine that disables ALL booting or boot modifiers except to the selected boot device?

You have got to be sh*tting me.
Nope, that's not what I'm saying.

What I'm trying to get at - okay - SU mode has always been insecure, given. OFW passwrods are inherently insecure - given.
Currently, in Tiger, if a user has anough savvy to try SU boot, he/she is given the instructions to finish booting a fully loaded CLI system (which previouls required some UNIX knowledge to get passed the crippled SU default boot of Panther or Jag). Now they are in a fully, internet enabled OS, as root, curtisy of Apple's own instructions at the final SU boot screen. This is just blantant advertising of the features of SU, to those who need not know.

And I still believe that any boot process, other then the default GUI login screen, SHOULD require a password - SU mode is usefull at times, but why should it, by default, be unautheticated?
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 09:18 PM
 
Originally Posted by ManOfSteal
piracy vs. Kvasir

Somebody just lost....badly.
What the hell does that post mean?? I just joined - one of my machines is named Kvasir, so I picked that??
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
May 4, 2005, 09:29 PM
 
Originally Posted by Kvasir
Nope, that's not what I'm saying.

What I'm trying to get at - okay - SU mode has always been insecure, given. OFW passwrods are inherently insecure - given.
Currently, in Tiger, if a user has anough savvy to try SU boot, he/she is given the instructions to finish booting a fully loaded CLI system (which previouls required some UNIX knowledge to get passed the crippled SU default boot of Panther or Jag). Now they are in a fully, internet enabled OS, as root, curtisy of Apple's own instructions at the final SU boot screen. This is just blantant advertising of the features of SU, to those who need not know.

And I still believe that any boot process, other then the default GUI login screen, SHOULD require a password - SU mode is usefull at times, but why should it, by default, be unautheticated?
Ok...

I think we all here, myself included, understand what your intent is here.

I'll even play devil's advocate for a second: you're saying that, by default, it's really easy to just hold a key combination, and within seconds, be at a root console. Then, right above the prompt, Apple prints a one-line command instructing you how to boot the OS, while remaining in single user mode, where you could ostensibly tinker with someone's files, install a keystroke logger, quickly copy selected files off the machine over the network, etc, and then reboot...perhaps all without the legitimate owner or administrator even knowing. And not only can you do all this, but Apple tells you how!

But here's where the argument falls down:

- If you're in single user mode, you're already root, and it's one command to enable full network access from single user mode. At which point, you can install, copy, etc., as you wish. In fact, you could argue that it's *quicker* to do whatever malicious deed you're out to do from the command line rather than the graphical interface.

- If you're attempting a boot into single user mode for malicious reasons, what is printed on the screen is utterly irrelevant.

- Advocating removal of the text is the worst possible solution, as if the underlying functionality is still present, this is essentially championing security through obscurity, which is no security at all

- Since the nature of single user mode is such that very few services are running, as it is a service, troubleshooting, and maintenance mode, there will not be advanced password and authentication services available, such as Open Directory or Directory Services. The basic authentication allowed for in single user mode requires that a basic password be assigned to root. In this case, that means a very insecure <8 character crypt hash.

- Enabling a crypt hash on root for the SOLE purpose of single user mode authentication actually, on balance, probably makes your machine MORE insecure, and potentially MORE vulnerable to local, even remote, root exploits. Further, someone could take the crypt hash to another machine, and crack it at their leisure. Leaving root disabled reduces your exposure to several vectors of attack greatly.

- Even if you did have authentication enabled, you can still:

* Boot the machine from a CD, and reset passwords at will, including root's
* Boot into target disk mode, where the drives contents can be pilfered with no evidence trail
* Boot from other external volumes, and access the contents of the internal drive
* And so on

The answer, of course, is to enable the Open Firmware password, which prevents all of these.

Which also - wait for it - prevents booting into single user mode at all, making the entire authentication argument for single user mode irrelevant.

I hope I've made this sufficiently clear.
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 09:33 PM
 
I guess my point is that other UNIX's do NOT, by default, allow a UID 0 login without some nefarious manipulation (Solaris, IRIX, AIX,...). Tiger just has it sitting out there.

Non-standard logins (ie. other than the GUI login screen) should require authentication - it's really not that bizarre a concept (given physical acces or whatever), and I really think Apple dropped the ball on that one. They've now blatanlty advertised it in Tiger's Su bootup screen.

if, as I've known from years ago, the MacNN cruisers want to call me a troll, uneducated, unintellegent, uninformed, unknowledgeable - then go ahead. Been there before (probably long before most of you registered) - that's why I left this place years ago - thought I might come back and get some other responses other than "Apple is always right" or "Apple's way is the only way", or "You don't know squat, I've been using Apple for a whole month, so I know everything".

Whatever - Su mode is a flaw - Apple knows it, and I understand there will be changes to it in the coming future.
     
Ganesha
Senior User
Join Date: Jul 2002
Location: Arizona Wasteland
Status: Offline
Reply With Quote
May 4, 2005, 09:37 PM
 
Just super glue down the S, C, O and F keys.
     
real
Grizzled Veteran
Join Date: May 2001
Location: Ca
Status: Offline
Reply With Quote
May 4, 2005, 09:37 PM
 
Originally Posted by Kvasir
What the hell does that post mean?? I just joined - one of my machines is named Kvasir, so I picked that??

Oh! Don't get all Fired up, it's a joke. You really didn't lose anything.
With some loud music + a friend to chat nearby you can get alot done. - but jezz, I'd avoid it if I had the choice---- If only real people came with Alpha Channels.......:)
AIM:xflaer
deinterlaced.com
     
TETENAL
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
May 4, 2005, 09:39 PM
 
Originally Posted by Kvasir
And I still believe that any boot process, other then the default GUI login screen, SHOULD require a password
So then why don't you enable Open Firmware password?
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 09:49 PM
 
Originally Posted by piracy
Ok...

I think we all here, myself included, understand what your intent is here.

I'll even play devil's advocate for a second: you're saying that, by default, it's really easy to just hold a key combination, and within seconds, be at a root console. Then, right above the prompt, Apple prints a one-line command instructing you how to boot the OS, while remaining in single user mode, where you could ostensibly tinker with someone's files, install a keystroke logger, quickly copy selected files off the machine over the network, etc, and then reboot...perhaps all without the legitimate owner or administrator even knowing. And not only can you do all this, but Apple tells you how!

But here's where the argument falls down:

- If you're in single user mode, you're already root, and it's one command to enable full network access from single user mode. At which point, you can install, copy, etc., as you wish. In fact, you could argue that it's *quicker* to do whatever malicious deed you're out to do from the command line rather than the graphical interface.

- If you're attempting a boot into single user mode for malicious reasons, what is printed on the screen is utterly irrelevant.

- Advocating removal of the text is the worst possible solution, as if the underlying functionality is still present, this is essentially championing security through obscurity, which is no security at all

- Since the nature of single user mode is such that very few services are running, as it is a service, troubleshooting, and maintenance mode, there will not be advanced password and authentication services available, such as Open Directory or Directory Services. The basic authentication allowed for in single user mode requires that a basic password be assigned to root. In this case, that means a very insecure <8 character crypt hash.

- Enabling a crypt hash on root for the SOLE purpose of single user mode authentication actually, on balance, probably makes your machine MORE insecure, and potentially MORE vulnerable to local, even remote, root exploits. Further, someone could take the crypt hash to another machine, and crack it at their leisure. Leaving root disabled reduces your exposure to several vectors of attack greatly.

- Even if you did have authentication enabled, you can still:

* Boot the machine from a CD, and reset passwords at will, including root's
* Boot into target disk mode, where the drives contents can be pilfered with no evidence trail
* Boot from other external volumes, and access the contents of the internal drive
* And so on

The answer, of course, is to enable the Open Firmware password, which prevents all of these.

Which also - wait for it - prevents booting into single user mode at all, making the entire authentication argument for single user mode irrelevant.

I hope I've made this sufficiently clear.
I understand what you are saying. But..I know how to lock down a Solaris machine, an SGI machine, an AIX machine, even a Linux machine, so no BIOS/firmware password is needed to do just about anything, let alone boot to root, without authentication. So why does a Mac need this (ie. an OFW password - the OS should dis-allow this kind of thing anyway), in the first place? It should not be possible to simply get a UID 0 login - period, not without authentication of some sort, or radical hardware manipulations?
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 09:50 PM
 
Originally Posted by real
Oh! Don't get all Fired up, it's a joke. You really didn't lose anything.
Eh, sorry, not trying to be a snit - just tired and all!

But I didn't get it anyways??
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
May 4, 2005, 09:58 PM
 
On Solaris, AIX, and Linux, single user mode is a reboot and a keystroke (or two) away. Granted, most require a root password, because, traditionally, root is enabled on these machines. Typically, the password is still a crypt hash. (You can also boot any of these OSes from installation media and acquire root access WITHOUT a password.)

But there is an important distinction you're missing:

Most Solaris, AIX, Linux, and other commercial UNIX machines are usually acting in a server role, in at least a quasi-secure environment or a datacenter. Physical access doesn't matter. And, you don't have a bunch of untrusted random users with local access to the machine, as you might in a lab or public setting. Mac OS X machines are used in a manifestly different way. If Mac OS X had the root password set as a crypt hash, ANYONE could take it, and beat on it for however long it took and have the root password.

On balance, enabling any root-level simple hash authentication, whether it's crypt or something else, brings MORE vulnerabilities to the platform than the "security" gained by requiring authentication in single user mode.

And I am still dumbfounded by your outright refusal to acknowledge that an Open Firmware password DISALLOWS THIS.

Leaving root DISABLED, i.e., with no password set (which is different from a "blank" password), is a longstanding enterprise security best practice on Mac OS X client machines. (On Mac OS X Server in secure environment, the root password is typically set in accordance with the local policies of the organization. By default, and unlike Mac OS X client post-10.0, it is set to the first local administrator's password.)

But the bottom line here is this: if you wish to eliminate casual exposure by single user mode, enable an Open Firmware password. If you do NOT enable an open firmware password, you are still open to numerous methods that allow local root-level access. Therefore, you NEED to enable an Open Firmware password. Once the Open Firmware password is set, you CANNOT boot into single user mode at all, making the authentication argument moot. The reason Mac OS X handles it differently than, say, AIX or Solaris, or even Mac OS X Server, is because it is usually used in an entirely different way, and therefore needs security practices and policies most appropriate to the situation. The Open Firmware password is the solution in publicly exposed Mac OS X machines, and no one will be delaying deployments based on your assertion.

Your calls for "some form of authentication" for a non-standard boot already exists: it's called an Open Firmware password.

Further, no, the behavior of single user mode on Mac OS X will not be changing in the foreseeable future.
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 09:59 PM
 
Originally Posted by piracy
Ok...

I think we all here, myself included, understand what your intent is here.

I'll even play devil's advocate for a second: you're saying that, by default, it's really easy to just hold a key combination, and within seconds, be at a root console. Then, right above the prompt, Apple prints a one-line command instructing you how to boot the OS, while remaining in single user mode, where you could ostensibly tinker with someone's files, install a keystroke logger, quickly copy selected files off the machine over the network, etc, and then reboot...perhaps all without the legitimate owner or administrator even knowing. And not only can you do all this, but Apple tells you how!

But here's where the argument falls down:

- If you're in single user mode, you're already root, and it's one command to enable full network access from single user mode. At which point, you can install, copy, etc., as you wish. In fact, you could argue that it's *quicker* to do whatever malicious deed you're out to do from the command line rather than the graphical interface.

- If you're attempting a boot into single user mode for malicious reasons, what is printed on the screen is utterly irrelevant.

- Advocating removal of the text is the worst possible solution, as if the underlying functionality is still present, this is essentially championing security through obscurity, which is no security at all

- Since the nature of single user mode is such that very few services are running, as it is a service, troubleshooting, and maintenance mode, there will not be advanced password and authentication services available, such as Open Directory or Directory Services. The basic authentication allowed for in single user mode requires that a basic password be assigned to root. In this case, that means a very insecure <8 character crypt hash.

- Enabling a crypt hash on root for the SOLE purpose of single user mode authentication actually, on balance, probably makes your machine MORE insecure, and potentially MORE vulnerable to local, even remote, root exploits. Further, someone could take the crypt hash to another machine, and crack it at their leisure. Leaving root disabled reduces your exposure to several vectors of attack greatly.

- Even if you did have authentication enabled, you can still:

* Boot the machine from a CD, and reset passwords at will, including root's
* Boot into target disk mode, where the drives contents can be pilfered with no evidence trail
* Boot from other external volumes, and access the contents of the internal drive
* And so on

The answer, of course, is to enable the Open Firmware password, which prevents all of these.

Which also - wait for it - prevents booting into single user mode at all, making the entire authentication argument for single user mode irrelevant.

I hope I've made this sufficiently clear.

Hey, so just to mention - editing /etc/ttys in Jag made things such that you did need to authentifcate (with an admin password) in order to complete even the basic boot into SU mode. That hasen't worked since Panther - secureit was an option in Panter (secureit made it essential to still sudouser authenticat in order to SU boot). So where in Tiger does one make any console login secure? I'm still figuring out lauchd and it plist daemons, and rc scripts have clearly changed radically, so where can one make ALL console logins secure??
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
May 4, 2005, 10:04 PM
 
Originally Posted by Kvasir
Hey, so just to mention - editing /etc/ttys in Jag made things such that you did need to authentifcate (with an admin password) in order to complete even the basic boot into SU mode. That hasen't worked since Panther - secureit was an option in Panter (secureit made it essential to still sudouser authenticat in order to SU boot). So where in Tiger does one make any console login secure? I'm still figuring out lauchd and it plist daemons, and rc scripts have clearly changed radically, so where can one make ALL console logins secure??
I think what we have here is a failure to communicate, as it were.

Let me see if I can be sufficiently explicit:

Requiring a secure console also requires a root password be set with a crypt hash. This is a Really Bad Thing, and opens you up to a whole new collection of exploit vectors, including someone taking the hash and cracking the root password at their leisure - and without your knowledge - leaving you in an even worse situation than the one you are purporting to solve.

Further, if you enable an Open Firmware password, ALL alternate boot methods require authentication. (And yes, the OF password can be administered remotely as part of centralized management.)

To repeat, on a Mac OS X machine in a public setting, which is the type of machine you are trying to secure, you are statistically LESS secure by enabling root with a crypt hash. Do you understand this? Do you understand that enabling the Open Firmware password ameliorates this problem completely?

Any more repetitive protests from you, especially ones that completely ignore or fail to respond in any way to the fact that you're less secure with the crypt hash for root, or my repeated recommendations regarding an Open Firmware password will confirm once and for all that you are trolling.
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 4, 2005, 10:12 PM
 
Originally Posted by piracy
On Solaris, AIX, and Linux, single user mode is a reboot and a keystroke (or two) away. Granted, most require a root password, because, traditionally, root is enabled on these machines. Typically, the password is still a crypt hash. (You can also boot any of these OSes from installation media and acquire root access WITHOUT a password.)

But there is an important distinction you're missing:

Most Solaris, AIX, Linux, and other commercial UNIX machines are usually acting in a server role, in at least a quasi-secure environment or a datacenter. Physical access doesn't matter. And, you don't have a bunch of untrusted random users with local access to the machine, as you might in a lab or public setting. Mac OS X machines are used in a manifestly different way. If Mac OS X had the root password set as a crypt hash, ANYONE could take it, and beat on it for however long it took and have the root password.

On balance, enabling any root-level simple hash authentication, whether it's crypt or something else, brings MORE vulnerabilities to the platform than the "security" gained by requiring authentication in single user mode.

And I am still dumbfounded by your outright refusal to acknowledge that an Open Firmware password DISALLOWS THIS.

Leaving root DISABLED, i.e., with no password set (which is different from a "blank" password), is a longstanding enterprise security best practice on Mac OS X client machines. (On Mac OS X Server in secure environment, the root password is typically set in accordance with the local policies of the organization. By default, and unlike Mac OS X client post-10.0, it is set to the first local administrator's password.)

But the bottom line here is this: if you wish to eliminate casual exposure by single user mode, enable an Open Firmware password. If you do NOT enable an open firmware password, you are still open to numerous methods that allow local root-level access. Therefore, you NEED to enable an Open Firmware password. Once the Open Firmware password is set, you CANNOT boot into single user mode at all, making the authentication argument moot. The reason Mac OS X handles it differently than, say, AIX or Solaris, or even Mac OS X Server, is because it is usually used in an entirely different way, and therefore needs security practices and policies most appropriate to the situation. The Open Firmware password is the solution in publicly exposed Mac OS X machines, and no one will be delaying deployments based on your assertion.

Your calls for "some form of authentication" for a non-standard boot already exists: it's called an Open Firmware password.

Further, no, the behavior of single user mode on Mac OS X will not be changing in the foreseeable future.
Piracy - I'm hearing ya'. Just we've avoided doing this just to avoid the annoyance of another password. Some have said we should just use the same as admin (our users do not have admin , clearly - their local folder is wiped at logout, and they must use our secure file server to permanently put files during a login session). While we could make the OFW password the same as admin, I'm against that.

So we'll need to go to an OFW password, I guess. That's not too bad, but I'd still like to see the SU boot screen in Tiger altered ( ). Our issue is primarly that our users have 24/7 access to the machines, and (largely) unlimited internet access on those machines (can't help that - just deal with it - public Univ., so you can't overly limit users access nor use of the machines).

Thanks - my issue is, I guess, a matter of, I want it to be the way I have it on other machines, but that don't work on Mac's
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 4, 2005, 11:33 PM
 
Okay... it's like this.

The Open Firmware password is something you want to turn on anyway in any public setting, because otherwise, even if single-user mode did not exist, anyone could just come in with a boot CD. So given that the Open Firmware password will be set, Single-User mode will be disabled. If someone cracks open the machine, they can get around the password and boot into single-user mode. True. But, they could also boot from a boot CD. They could also take your hard drive out.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
OpenStep
Senior User
Join Date: May 2001
Location: Boston, MA
Status: Offline
Reply With Quote
May 4, 2005, 11:37 PM
 
wow
     
moki
Ambrosia - el Presidente
Join Date: Sep 2000
Location: Rochester, NY
Status: Offline
Reply With Quote
May 5, 2005, 12:47 AM
 
Piracy is quite correct, as are others who have chimed in here. Tiger is no different from Cheetah, Puma, Jaguar, or Panther. On any of these incarnations of MacOS X, if you have physical access to the machine, unless proper measures are taken, you can boot as root.

That a screen with instructions was added means little; anyone who is savvy enough to boot into single user mode is savvy enough to know how to continue the boot process.

Disable it with OF if you're that concerned.
Andrew Welch / el Presidente / Ambrosia Software, Inc.
     
Art Vandelay
Professional Poster
Join Date: Sep 2002
Location: New York, NY
Status: Offline
Reply With Quote
May 5, 2005, 01:16 AM
 
Originally Posted by Kvasir
Piracy - I'm hearing ya'. Just we've avoided doing this just to avoid the annoyance of another password. Some have said we should just use the same as admin (our users do not have admin , clearly - their local folder is wiped at logout, and they must use our secure file server to permanently put files during a login session). While we could make the OFW password the same as admin, I'm against that.

So we'll need to go to an OFW password, I guess. That's not too bad, but I'd still like to see the SU boot screen in Tiger altered ( ). Our issue is primarly that our users have 24/7 access to the machines, and (largely) unlimited internet access on those machines (can't help that - just deal with it - public Univ., so you can't overly limit users access nor use of the machines).

Thanks - my issue is, I guess, a matter of, I want it to be the way I have it on other machines, but that don't work on Mac's
These are public, university machines and you've never put an OF password on them? That's insane!
Vandelay Industries
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 5, 2005, 06:16 AM
 
Well, here's a question - can you reboot a machine with Apple Remote Desktop (eg. after mass installing a security patch or upgrade) with OFW passwords enabled? I can just try this tomorrow, but if someone knows, I'd appreciate the info.

And okay, I'll grant it's not a security flaw per se, but I still think it's silly that a default install allows any user to boot to runlevel 1 and be given a root shell without being asked to provide a password. What's the whole point of passwords then anyway? It's poor form, at the least.
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
May 5, 2005, 06:41 AM
 
Originally Posted by Kvasir
Well, here's a question - can you reboot a machine with Apple Remote Desktop (eg. after mass installing a security patch or upgrade) with OFW passwords enabled? I can just try this tomorrow, but if someone knows, I'd appreciate the info.
Even if you could, it wouldn't matter much. In the process of shutting down or rebooting the machine you would deactivate the ARD server, which would in turn disconnect you. You would then not be able to reconnect, because the OF password would prevent the system -and, by extension, the ARD server- from starting up.

End result: the worst anyone could do is cause the machine to shut down. A malicious user could not get root access in this way. Of course, even if Shut Down is allowed from ARD (which I'm not entirely sure it is), then it will almost certainly require a password. This is something mAxximo has complained about numerous times, but now we see the reason for its existence.
And okay, I'll grant it's not a security flaw per se, but I still think it's silly that a default install allows any user to boot to runlevel 1 and be given a root shell without being asked to provide a password. What's the whole point of passwords then anyway? It's poor form, at the least.
Only with physical access. This is, hands-down, the best which can be hoped for. One extra boot password is not going to make any difference to someone who has physical access.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
May 5, 2005, 06:51 AM
 
This is a humorous thread. Kvasir still does not comprehend the greater vulnerability incurred by the creation of a single user password.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 5, 2005, 07:44 AM
 
But in other UNIX's you DO need to know the root password to run "init 1", or the GRUB/LiLo (or other bootloader) password to change the default runlevel. SuSe prompts for root password even after you have executed "init 1" when the system comes back up in runlevel 1 (or at least it used to).

Only OS X lets you negate all security by simply knowing which two keys to press during a restart.

And the whole "no security without physical security" is over-used. Of course you have to let users have access to machines - that doesn't mean you hand them admin/root permission on a platter.

Even with OFW passwords, the ability to effectively run init 1 without authority needs to go, IMO.

And ARD works fine for remotely installing patches and such, then telling the remote machine to reboot. But if OFW passwords block this, then a lot of the functionality of ARD for remote admininstration is gone.
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
May 5, 2005, 07:51 AM
 
My word, Kvasir. Piracy could not have explained it any clearer. The vaunted security of a weakly stored password that you so highly value on those other platforms is at best a minor deterrent and at worst a security vulnerability in its own right. Let the issue die. You're just plain wrong, and it does not take a Unix guru to make that determination.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
ghporter
Administrator
Join Date: Apr 2001
Location: San Antonio TX USA
Status: Offline
Reply With Quote
May 5, 2005, 08:14 AM
 
In most cases you place your workstations in a physical environment where anyone who can access the hardware has been vetted. You trust the people who can touch the hardware, so physical access is a non-issue.

In the far less common situation where you have public access to a workstation, it is common (and best) practice to lock down EVERYTHING to the point where any random individual can walk up, use the workstation within the limits the administrator has set, and do NOTHING MORE. Crafting the setup for this kind of workstation is a fine art, but with standardized hardware, a single solution is easily implemented on all installations of the same hardware. You also lock down external access to your servers such that the same limits-or even more stringent ones-are set. You further make sure your internal workstations are not exposed directly to the Internet so that they are not subject to external exploitation. The above is commonly referred to as "network security."

I really believe that this is a non-issue; you either trust the people inside your network, or you build a solid defense against any badness coming in through a publicly accessible workstation or through the Internet.

Glenn -----OTR/L, MOT, Tx
     
JLL
Professional Poster
Join Date: Apr 1999
Location: Copenhagen, Denmark
Status: Offline
Reply With Quote
May 5, 2005, 12:51 PM
 
Originally Posted by Millennium
Of course, even if Shut Down is allowed from ARD (which I'm not entirely sure it is), then it will almost certainly require a password.
Yes, it's there but it behaves the exact same way as if you chose Shut Down from the Apple menu - and you need a password to control the machine anyway.
JLL

- My opinions may have changed, but not the fact that I am right.
     
ReggieX
Professional Poster
Join Date: Oct 2000
Location: Toronto, ON
Status: Offline
Reply With Quote
May 5, 2005, 12:55 PM
 
Originally Posted by Ganesha
Just super glue down the S, C, O and F keys.
Then how am I supposed to join in the anti-SCO articles on Slashdot?
The Lord said 'Peter, I can see your house from here.'
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 5, 2005, 01:21 PM
 
Originally Posted by Millennium
Even if you could, it wouldn't matter much. In the process of shutting down or rebooting the machine you would deactivate the ARD server, which would in turn disconnect you. You would then not be able to reconnect, because the OF password would prevent the system -and, by extension, the ARD server- from starting up.
Only if you set the OF security-mode to full. If you set it to command instead, it'll let you boot from the main disk, but just block you from booting into single-user mode or from a disk other than the startup disk (i.e. a boot CD).

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
May 5, 2005, 01:34 PM
 
Originally Posted by CharlesS
Only if you set the OF security-mode to full. If you set it to command instead, it'll let you boot from the main disk, but just block you from booting into single-user mode or from a disk other than the startup disk (i.e. a boot CD).
Will it still do that if you've set the password? I admit to not having much experience with OF passwords, but wouldn't it just keep sitting there waiting for the password, which you couldn't enter from the remote machine you booted from because there's no ARD server?
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 5, 2005, 01:55 PM
 
Originally Posted by Millennium
Will it still do that if you've set the password? I admit to not having much experience with OF passwords, but wouldn't it just keep sitting there waiting for the password, which you couldn't enter from the remote machine you booted from because there's no ARD server?
There are three security modes for Open Firmware. The first one is 'none', which as you might expect does not restrict you in any way. This is the default. The second is 'command', which lets you boot from the startup disk, but to do just about anything else - boot from external disk, single-user, OF commands, etc. - you need to know the password. The third is 'full', and if you set this one, you'll literally need the password to do anything, even boot the machine. This seems to be what you want. In many cases, though, this is overkill, since you want the user to be able to boot, you just don't want him messing with stuff like boot CDs and single-user mode.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
May 5, 2005, 10:05 PM
 
Originally Posted by CharlesS
There are three security modes for Open Firmware. The first one is 'none', which as you might expect does not restrict you in any way. This is the default. The second is 'command', which lets you boot from the startup disk, but to do just about anything else - boot from external disk, single-user, OF commands, etc. - you need to know the password. The third is 'full', and if you set this one, you'll literally need the password to do anything, even boot the machine. This seems to be what you want. In many cases, though, this is overkill, since you want the user to be able to boot, you just don't want him messing with stuff like boot CDs and single-user mode.
You know, it seems like command mode is what Kvasir wants, then. It password protects the single-user mode, but lets the machine boot from its own startup disk without anyone having to know what the password is.

How is that different from setting the root password on other machines to prevent booting into single user mode, other than the fact that it can be defeated by modifying the hardware. And in a public computer lab setting, someone would have to be absolutely stupid to try to defeat a locked case let alone try physically removing the hard drive without being noticed by someone.
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 6, 2005, 12:00 AM
 
Originally Posted by Person Man
You know, it seems like command mode is what Kvasir wants, then. It password protects the single-user mode, but lets the machine boot from its own startup disk without anyone having to know what the password is.

How is that different from setting the root password on other machines to prevent booting into single user mode, other than the fact that it can be defeated by modifying the hardware. And in a public computer lab setting, someone would have to be absolutely stupid to try to defeat a locked case let alone try physically removing the hard drive without being noticed by someone.
An Open Firmware password is exactly what Kvasir wants; he just doesn't realize it. This is the reason why Apple tech support recommended it to him. Yeah, it can be defeated by modifying the hardware, but a password on single-user mode can be defeated with a boot CD. And that is much less conspicuous than opening the case...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
May 6, 2005, 12:31 AM
 
Originally Posted by CharlesS
...a password on single-user mode can be defeated with a boot CD. And that is much less conspicuous than opening the case...
Exactly.
     
Kvasir  (op)
Forum Regular
Join Date: May 2005
Status: Offline
Reply With Quote
May 6, 2005, 07:38 PM
 
I have read everything in this thread so bear with me, and excuse my earlier, ranting (for lack of a better term).

I understand piracy's information, and get it - OFW passwords are the way to go with OS X.

And all this isn't really an issue for personal users who watch over their own machines - but it still is for schools, universities and such, that by definition, have public access machines (sometimes hundreds of 'em - oh, and I realize now that ARD 2 works just fine with OFW passwords - actually has a whole feature to work with them, so that removes all of my issues with using them in the first place).

So, it still seems to raise some questions for me. Is Apple the only computer/OS OEM out there that allows a simple keyboard shortcut root exploit by default? (to my knowledge they are). Every other UNIX, for better or worse, requires that to run init 1 (runlevel 1) knows something about the root/bootloader/admin password - it cannot be done with a simple default keyboard shortcut (well, knoppix notwithstanding, but it's a special distro).

If OFW passwords are the answer to true security, why isn't Apple's own OFW password utility included with a default install of OS X, with instructions of how, and why, to use it?

And please don't preach about how secure OS X is. Apple ignored the well publicized virtual memory (swap file) exploit (ie. grepping for clear text passwords in swap on un-restarted machines) - that has only been addressed in Tiger (and even that's a bit buried), and there is still no fix for Panther nor Jag. That exploit essentially negates file fault, and for those concered about such extreme data security, it was an issue (especially for laptops, that could be stolen, booted in firewire target mode, and then fully exploited).

So, if OFW passwords are the answer to the "feature" of a keyboard shortcut to single user mode, then why doesn't Apple shout that to the world of its users? And include it's own utility for invoking them with every OS X DVD and CD?

I'm serious - I understand what's been discussed here, but if OFW is the ultimate security model to negate root exploits on Apple machines, why isn't it right up there with "how to install OS X"? It needs to be better publicized - or even, have an option, to allow or disallow the keyboard single user shortcut during install (ie. to get rid of it, and force single user only from a terminal session by a aquthorized admin/root).

I still just think this is a poor model for an OS that so proudly claims it's emphasis on security.
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
May 6, 2005, 08:33 PM
 
Originally Posted by Kvasir
If OFW passwords are the answer to true security, why isn't Apple's own OFW password utility included with a default install of OS X, with instructions of how, and why, to use it?
Because Mac OS X is also marketed to consumers. The feature is there on the install disks for those people who need to use it... Insert the Tiger install disk. Go to Applications/Utilities/ on the disk. There's the OFW Utility... INCLUDED on the install disk.

Also, it's clearly mentioned in Mac OS X Help. It's not on the installer screen because it doesn't need to be. It would be all too easy for someone to accidentally enable it that way. But it's easily enabled by those who need it.

And please don't preach about how secure OS X is. Apple ignored the well publicized virtual memory (swap file) exploit (ie. grepping for clear text passwords in swap on un-restarted machines) - that has only been addressed in Tiger (and even that's a bit buried), and there is still no fix for Panther nor Jag. That exploit essentially negates file fault, and for those concered about such extreme data security, it was an issue (especially for laptops, that could be stolen, booted in firewire target mode, and then fully exploited).
Ok, so that problem totally negates the rest of the security features of Mac OS X?

So, if OFW passwords are the answer to the "feature" of a keyboard shortcut to single user mode, then why doesn't Apple shout that to the world of its users? And include it's own utility for invoking them with every OS X DVD and CD?
Apple is the one who told you to use it. And the DO include a utility on every install CD and DVD that you can use to enable it, see above.

I'm serious - I understand what's been discussed here, but if OFW is the ultimate security model to negate root exploits on Apple machines, why isn't it right up there with "how to install OS X"? It needs to be better publicized - or even, have an option, to allow or disallow the keyboard single user shortcut during install (ie. to get rid of it, and force single user only from a terminal session by a aquthorized admin/root).
It's NOT positioned as the "be all end all" of preventing root exploits. It is far more secure to leave the root account disabled on a typical Mac OS X account than it is to enable it with a password. You can't remotely log into an account that's disabled. The OFW password only makes it more difficult for someone with physical access to the machine to gain root access. Not impossible. In fact it is impossible to completely secure a machine if a person has direct access to it. You can only make it reasonably so.

And as far as having "an option, to allow or disallow the keyboard single user shortcut during install (ie. to get rid of it, and force single user only from a terminal session by a aquthorized admin/root)" goes, it's there. IT'S THE OPEN FIRMWARE PASSWORD, SILLY!

Seriously. Once the password is set, people can no longer boot into single user mode unless they're authorized to do so (i.e. they have the OFW password). Don't give the OFW password to someone not authorized to boot into single user mode. Period.

Not only that, but if you could set a separate password to single user mode independently of the OFW password, someone could still walk in with a startup disk and get around the password...
( Last edited by Person Man; May 6, 2005 at 09:04 PM. )
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
May 6, 2005, 11:00 PM
 
I don't know why you're stuck on calling it a "root exploit" (it's not, and any argument that it is would be VERY semantically shaky, to say the least).

This is a documented, known feature of Mac OS X. And no, this isn't a case of "calling a security risk a feature!!!" or anything like that.

I have already explained the reasons to you, and you won't listen:

- Mac OS X does NOT require a root password for single user mode because the nature of the underlying BSD elements that are utilized for single user mode, and the nature of single user mode itself, REQUIRES that the root password be stored in a very simple way; in this case, a crypt hash that represents a >8 char password. This is NOT GOOD in the context of the usage style of most Mac OS X machines, and exposes them to substantially more risk than simply leaving the root password inactive.

- ANY institutional deployment that has even a small clue about what it's doing will deploy in public/untrusted areas with Open Firmware passwords, negating your entire issue with single user mode. There isn't much more to say here. When people have casual physical access, the mode of protection comes via Open Firmware password, period. They can be centrally managed (as you've found), and don't prevent you from doing any legitimate administrative tasks, local or remote.

- To repeat: your insistence on continuing to focus on only the authentication in single user mode implies that an Open Firmware password is NOT set, as that is the ONLY way it's an issue...and when an Open Firmware password is NOT set, you can:

* Boot from a Mac OS X install CD and reset all passwords, including root
* Boot from other bootable volumes
* Boot in target disk mode

Any "but it's easier" arguments are invalid, because it's VERY easy for someone so inclined to carry around a bus-powered bootable FireWire drive and do anything at will.

And of course, this whole last argument is ridiculous anyone, because since an Open Firmware password is REQUIRED to prevent all of these other things, you AUTOMATICALLY disable single user mode to unauthorized users. On top of which, an Open Firmware password is much harder to defeat, and doesn't expose you to any greater level of vulnerability at the OS level.

I already said that most other UNIXes require a root password in single user mode. But this isn't for "security", per se; this is for manyfold and historical reasons, not to mention that fact that as a matter of course, all of these systems will have root passwords set, and in fact depend on them. This is viewed as a liability! Apple found that Mac OS X does not have to suffer from this liability, and can therefore ship with root DISABLED. Further, they offer comprehensive alternate boot prevention at the firmware level in the machine.

Take "yes" for an answer.
     
 
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 05:39 PM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,