[ebsidohw]

yup I agree... the FreeBSD core is very secure.

[Graymalkin]

Windows is a popular platform for viruses because it is popular and insecure. Linux and OSX are relatively popular, at least to the point of showing up as major statistical points, but are quite a bit more secure than Windows. There's enough Mac or Linux users floating about that some sort of major Nimda or Blaster level worm would cause quite a ruckus. Their level of out of the box security and robustness is quite a bit higher than that of Windows.

Back to the original topic, I think OSX's security and robustness ought to be touted whenever possible. While it is extremely likely someone will come out with a devastating Mac-centric worm in the future for now OSX has an excellent record. When someone asks me about my Powerbook or OSX one of the first things I tend to mention is the fact I don't end up with viruses in my e-mail or exploits crashing my machine when I hop on the internet. I can't be bothered to use an OS fulltime that can't manage to stay online for more than a few minutes without being violated in some fashion buy some 15 year old.

[utidjian]

Originally posted by besson3c:
When you log out, all processes owned by you are killed off - including ones that have been backgrounded. Try putting a VNC server into the background and logging off.

You could just throw it into the login items list though, but I'm not sure if scripts can be added to this list. The virus is pretty obvious when it is sitting there in your dock.

Re: shadow passwords... how does NetInfo fit into this picture?

Example:

Open a terminal on your Mc either locally or log in remotely.
Run the command "screen" (without the quotes).
In the screen session run the command "top".
Type Ctrl+A+D to "detach" your screen.
Logout.

Log in as a different (or the same user) and type ps aux or top or whatever. You will see that the screen session and the other top are still running. If you want to kill that screen session just log in as the user who started it and type "screen -r" (for resume) and quit out of whatever you were doing ("q" for top) and Ctrl+D will kill the terminal login.

There are other ways other than screen to create processes and sessions that won't die when you log out.

There are also ways to start things that won't show up in your dock.

I think it is more of how do shadow passwords fit into NetInfo. Shadow passwords have been around for at least 15 years now. OSX got them a year ago (I forget exactly when Panther came out.) NetInfo is going away eventually. I think Apple is moving towards OpenLDAP/Kerberos kind of networked database for authentication and authorization.

[Love Calm Quiet]

utidgian...

I appreciate your thoughtful observations and information.

Could you speak a little about what the implications may be if "Apple is moving towards OpenLDAP/Kerberos kind of networked database for authentication and authorization." ?

Thanks.

[legacyb4]

Nor are any of the shared services enabled by default either.

Originally posted by utidjian:
Urm... I don't think the firewall is enabled by default. It is very easy to turn it on though.

[besson3c]

Originally posted by utidjian:
Example:

Open a terminal on your Mc either locally or log in remotely.
Run the command "screen" (without the quotes).
In the screen session run the command "top".
Type Ctrl+A+D to "detach" your screen.
Logout.

Log in as a different (or the same user) and type ps aux or top or whatever. You will see that the screen session and the other top are still running. If you want to kill that screen session just log in as the user who started it and type "screen -r" (for resume) and quit out of whatever you were doing ("q" for top) and Ctrl+D will kill the terminal login.

Ahh... okay, using screen.

I was thinking of bg.

I think it is more of how do shadow passwords fit into NetInfo. Shadow passwords have been around for at least 15 years now. OSX got them a year ago (I forget exactly when Panther came out.) NetInfo is going away eventually. I think Apple is moving towards OpenLDAP/Kerberos kind of networked database for authentication and authorization.

So the Shadow passwords are not saved into the NetInfo Database?

[utidjian]

Originally posted by Love Calm Quiet:
utidgian...

I appreciate your thoughtful observations and information.

Could you speak a little about what the implications may be if "Apple is moving towards OpenLDAP/Kerberos kind of networked database for authentication and authorization." ?

Thanks.

The "implications" are, mainly, that Macs will be more easily integrated into corporate and academic heterogenous networks. For the home user it will not make that much difference. Apple calls its version of OpenLDAP Open Directory. There are many implementations of LDAP and things that also work a lot like it. NIS, NIS+, NetInfo are all earlier versions of a "networked directory" or "networked database" service. MS Active Directory, Novell eDirectory, Open Directory are all versions of the new "paradigm" (now this post is buzzword compliant ;-)) in directory services.

The whole idea behind directory services (of whatever implementation) is to make it easier, even possible, to manage a multi-user multi-platform network of computers. With a single centralized control model (the directory services may actually be, and usually are, hosted on a number of separate servers) one can control user authentication and and authorization. Authorization is what a user can DO once they have been authenticated. In short, it makes it a lot easier to manage networked services.

For much more info on this you can read the stuff Apple has published on the topic at:
http://www.apple.com/server/macosx/open_directory.html
A good lightweight intro (as it relates to Apple) are the Technology Briefs (right side of above link) in PDF format.
Also check out:
http://www.openldap.org
they have a pretty good FAQ/Wiki thing.

As before... for the home user with a few Macs this is no big deal, though it will certainly make things a LOT simpler if you share files and printers and other services between these systems. Apple will most likely make a very simple interface for configuring all this. If you have a mixed home network it should be even easier than it is now.
For small businesses and schools on up to large corporations and universities it will really make it possible to completely integrate Macs into their networks. For the end user it will just be all that more transparent.

Imagine, if you will, being able to sit down at ANY system (BSD, OSX, Linux, Windows, whatever) and be able to log in with the same userid and password you use at your regular desktop and have ALL your stuff right there... just the way you are used to it.

In the future... at some point, you will not only have all your "local" files a click away, but also all your files at home, at work, at school, wherever... all securely and transparently accessible from any desktop... all at the same time. This is possible now but it is a real bear to setup. OpenLDAP/LDAP et al, are a step in this direction.

[utidjian]

Originally posted by besson3c:
So the Shadow passwords are not saved into the NetInfo Database?

They are stored in /var/db/shadow/hash/

I have no idea whether a copy is also stored in NetInfo or not.

[Link]

I say tout it! The more exploits, the more experience the programmers get with preventing such things from happening. Good idea

[utidjian]

OK for a while now I have been rambling about a few things with regards to Mac OS X security. OSX security *record*, so far, has been rather good. Some have mentioned that part of this is due to OSX being based on BSD. Though no one seems to have considered that it is completely possible to _make_ a BSD system (approximately) AS insecure as most any Windows system. While the Mail.app may be far far more secure than, say, Outlook... there are also a large number of apps and services that are possible to run on an OSX system that may not be as secure.

I think that a large part of Mac OS X current security *record* is due to its relative obscurity... and has not all that much to do with what Apple has done. Perhaps even in spite of what Apple has done.

As an illustration:

This will be a problem primarily for home users with a default install (aka "out-of-the-box") of Mac OS X.

Log in to your Mac OS X system as the "primary user" or "owner"... the user who first ran or installed Mac OS X Panther on the system.

Drag and drop any old file from your desktop to the Applications folder.

1. Why is this possible?
2. Why would it be a good idea to make this possible?
3. More important, why not?
4. What implications does this have for the basic security of the system?
5. Would this make it any easier for a virus/worm/trojan to infect your system?
6. If you see this as security problem (I DO) how would you go about fixing it?
7. If the fix is very simple and basically breaks no functionality of the system would you apply the fix? (there is a simple fix)
8. Why is this (probably) not a major problem for schools and companies that may have many Mac OS X systems with many users?
9. Why could it be an even larger problem for schools and companies than for an individual system?
10. How would you answer the above questions when you are touting the security of Mac OS X?

[Link]

From an EXTERNAL point of view, OS X has been, currently is, and always will be more secure than any version of windows based on the NT kernel. I can say from any piece of knowledge that this is NOT, in a million days, due to it's obscurity.

You can sit there and point at a 'default install standpoint', from which I could also go into the windows/system folder and trash a few DLLs. Geez so secure.

Usually the main point of security would be how secure the machine is on a large network. Plug an "out of the box" windows machine into a cable modem, now plug an "out of the box" mac into a modem on the exact same network, wait a few minutes and see what you get..

If you're on a large cable network, chances are the PC will reboot in a few minutes.

[utidjian]

Originally posted by Link:
From an EXTERNAL point of view, OS X has been, currently is, and always will be more secure than any version of windows based on the NT kernel. I can say from any piece of knowledge that this is NOT, in a million days, due to it's obscurity.

You can sit there and point at a 'default install standpoint', from which I could also go into the windows/system folder and trash a few DLLs. Geez so secure.

Usually the main point of security would be how secure the machine is on a large network. Plug an "out of the box" windows machine into a cable modem, now plug an "out of the box" mac into a modem on the exact same network, wait a few minutes and see what you get..

If you're on a large cable network, chances are the PC will reboot in a few minutes.

I agree with all of that... but I am talking about overall security. I have no doubt that an out-of-the-box OSX Panther system is more secure and less crackable than the equivalent ootb Windows-XP system. Yet... you can pick any single thing on either system and say this is more secure than that or less so. Problem is... the default permissions on /Applications can pretty much hose the entire system security with a well crafted trojan app. If one can imagine a way to do it... so can the ones that will eventually exploit it.

Security is a process not a single product or single program or single OS (there... now this post is buzzphrase compliant) Security is the sum of the parts of the system and how they interact within it and the outside. When one of those parts is weak it may weaken the security of the entire system.

I agree that it is a good idea to have most, if not all, services and ports turned off in an ootb installation of any OS. Yet at some point, for the system to be useful, it has to be plugged in to a network and certain ports will have to be opened and services enabled. Not all systems need them but many do.

I realize it is a tough mix to come up with. How to make a system reasonably secure yet easy for a user to administer. I think it should be made as secure as possible for the user/admin. I think it is possible to make Mac OS X MUCH more secure by changing the default perms on /Applications AND forcing the user/admin to create a regular user account.

Think about it and/or ask a Unix security admin.

[Link]

Yes, having total security is a pain in the ass...

But there's gotta be SOME form of um.. usefullness. These machines are mainly being sold to regular people, note when I say that, people who would LIKE to be able to posisbly screw up their system by trashing something in the apps folder.

So be it, a home OS and a work OS can't mix.

[qyn]

Originally posted by utidjian:
As an illustration:

This will be a problem primarily for home users with a default install (aka "out-of-the-box") of Mac OS X.

Log in to your Mac OS X system as the "primary user" or "owner"... the user who first ran or installed Mac OS X Panther on the system.

Drag and drop any old file from your desktop to the Applications folder.

Despite your extreme belaboring of the point, I think you're wrong.

Yes, admin users can install programs. The OS that disallows this is not much of an OS, IMHO. The difference between OS X and Windows is that there's no way on OS X to install a program by accident or inadvertently. This isn't a problem for business of school networks, either, because those users aren't admin (nor will the computer be left in the "out-of-the-box" configuration).

It sounds like you want some further password on app installs, but this is a bad idea. Users will hate this, and therefore always run as root (like XP). Read about the Principal of Psychological Acceptibility in Saltzer and Schroeder's Rules of Prudent Security Engineering.

Further, you listed this "as an illustration", suggesting there's other instances too. What are they?

[utidjian]

Originally posted by qyn:
Despite your extreme belaboring of the point, I think you're wrong.

What did I say that was "wrong"?

Yes, admin users can install programs. The OS that disallows this is not much of an OS, IMHO. The difference between OS X and Windows is that there's no way on OS X to install a program by accident or inadvertently. This isn't a problem for business of school networks, either, because those users aren't admin (nor will the computer be left in the "out-of-the-box" configuration).

I have nothing against members of group admin installing apps. Naturally, this has to be done by someone (duh).

I am not talking about Windows. I am talking about Mac OS X. I could really give a damn what happens with Windows except where it affects my networks. I am concerned that Mac OS X could develop similar problems.

Yes, there are many ways that an "rogue app" can be installed inadvertently. I gave a partial example earlier in this thread. It is far too easy IMO.

Yes I am aware at what goes on at schools. I work at one. Admin level users, when logged in as admin, can still install a "rogue app" far too easily... even inadvertently. I realize that this is far less likely to happen in a large multiuser environment than with a home user BUT the consequences can affect far more people IF it does happen.

It sounds like you want some further password on app installs, but this is a bad idea. Users will hate this, and therefore always run as root (like XP). Read about the Principal of Psychological Acceptibility in Saltzer and Schroeder's Rules of Prudent Security Engineering.

Yep. I think the mode on /Applications should be 0755. I think an admin level user should be either prompted for a password whenever there are going to be any changes made to the /Applications folder (writes and deletes) or, at the very least, "a click the lock to make changes" dialog for the installer some of which require a password. A password (as with sudo) doesn't have to be for every single act, there can be a reasonable timeout, but some sort of "click the lock" checkpoint should be there.

I am aware of what users will like and dislike. Remember the confusion and vehement dislike users had of OSX when it first came out? There is still much confusion about permission bits. Seems to be a problem for the suppliers of apps also. Can you name ANY other Unix or Unix-like OS that needs a Repair Disk Permissions utility? IIRC correctly it only "repairs" Apple installed stuff.
The admin of a machine does not have to install apps all that often. They have to authenticate for SoftwareUpdate.. why not for an install to /Applications? There is also the Principle of Least Privilege.

I agree that it is difficult balance of useability and security to make. In my opinion the current scheme is still too easy by default because it leaves a path open for someone to compromise it.

Further, you listed this "as an illustration", suggesting there's other instances too. What are they?

I mentioned earlier the problem of "nidump passwd ." Yes I know it has been fixed with the move to shadow passwords in 10.3 but it is still not applied well in the case of someone upgrading from 10.2.

I don't like the permissions of users home folders being mode 0755. They should be mode 0700 or, at most, 0711 by default.

Mac OS X should force users to choose a reasonably strong password. Many versions of Unix already do this. Yes, this can be frustrating for the user. It is much more frustrating to have a compromised account though.

[Graymalkin]

Changing the permissions on the /Applications folder isn't going to do much good in preventing "rogue apps" from running. An application bundle will run from anywhere which means it can be run from a CD, an iPod, or even a network mounted disk image. Requiring admins to jump through an extra hoop to install applications wouldn't add much security to the system. If an admin is going to install an app they are going to install it whether or not a password is required. The chances of a "rogue app" being installed remain the same even with tighter access control. Blocking rogue apps is more a job for the system's wetware rather than software.

[qyn]

Originally posted by utidjian:
What did I say that was "wrong"?

Your thesis seems to be that OS X has suffered from few attacks by luck only, perhaps in spite of what Apple has done.

And I disagree with both assertions. I think we can both agree that security on OS X is imperfect, and probably always will be. As I mentioned earlier in this thread, I'd like to see ipfw turned on by default, as one example. You listed an example with nidump.

But having lapses in security does not mean that OS X is not inherently more secure than Windows (if I might use an unwieldy double negative). I claim that it is inherently more secure, for the many reasons listed in this thread.

And it's clear that Apple is making forward progress in making OS X more secure (including fixing the nidump problem). So I can't agree with your suggestion that Apple is subverting the security of the BSD core.

I am not talking about Windows. I am talking about Mac OS X.

The argument is whether OS X is more secure than Windows. Running an executable on Windows is as easy as opening an email. Running an executable on OS X requires significantly more work. This makes OS X more secure.

The point I was trying to make earlier (and I think graymalkin actually made) is that to install an executable on OS X requires a user to take purposeful steps, which is enough to prevent Windows-style email attacks (which require absolutely no extra action on the part of the user). But if I download a program, I'm going to take the steps necessary to install it (including typing a password), regardless of whether it turns out to be a "rogue app". And I may end up permanently escalating my privileges because I get annoyed with typing passwords all the time. Then we have a real problem.

Further, if I have to type a password for my every move, then the significance of typing a password is lost. I'm more likely to not look at the thing that's asking for the password, and perhaps even willingly type it for the "rogue app" because I'm so used to typing it at all times.

I don't like the permissions of users home folders being mode 0755. They should be mode 0700 or, at most, 0711 by default.

Mac OS X should force users to choose a reasonably strong password.

Fair enough. We all have improvements we'd like to see, and OS X still has work to be done. But compare these complaints to what we might say of Windows:

-I don't like how Windows shares C$ and IPC$ by default
-I don't like how Windows runs applications with full privileges from email
-Windows shouldn't make the local user root by default

I mean, these types of improvements are in a completely different class than changing the default permissions of the users home directory.


Ultimately, I maintain that an "out-of-the-box" OS X machine, though not completely secure, is more secure than a Windows machine in the default configuration.

[utidjian]

Originally posted by Graymalkin:
Changing the permissions on the /Applications folder isn't going to do much good in preventing "rogue apps" from running. An application bundle will run from anywhere which means it can be run from a CD, an iPod, or even a network mounted disk image. Requiring admins to jump through an extra hoop to install applications wouldn't add much security to the system. If an admin is going to install an app they are going to install it whether or not a password is required. The chances of a "rogue app" being installed remain the same even with tighter access control. Blocking rogue apps is more a job for the system's wetware rather than software.

True. But only the person with the CD or iPod can run that app. For a regular user that pretty much limits it to what that user has permissions to do.

[utidjian]

Originally posted by qyn:
Your thesis seems to be that OS X has suffered from few attacks by luck only, perhaps in spite of what Apple has done.

Yes. Do you know what the basic standard security model for most Unixes is as regards file systems and permissions? When I say "in spite of what Apple has done" I mean that they have basically broken the rules on that model.

And I disagree with both assertions. I think we can both agree that security on OS X is imperfect, and probably always will be. As I mentioned earlier in this thread, I'd like to see ipfw turned on by default, as one example. You listed an example with nidump.

OK

But having lapses in security does not mean that OS X is not inherently more secure than Windows (if I might use an unwieldy double negative). I claim that it is inherently more secure, for the many reasons listed in this thread.

The "lapses" in this case was something done intentionally by Apple. I think I understand why they did it. But I don't have to agree with it and I can certainly, at least, wish it were better. With the current setup there are a few things I can do to alleviate this problem and I have done them. None of these things have made the systems I administer more difficult for my users to use.

As I (I think) said before... Windows is irrelevant to this discussion about Mac OS X security. Just because Windows does something similar or even worse with their systems is no excuse for Apple.

And it's clear that Apple is making forward progress in making OS X more secure (including fixing the nidump problem). So I can't agree with your suggestion that Apple is subverting the security of the BSD core.

I agree they are making progress. Show me a non-Apple BSD that has /usr/bin/, /opt/, /usr/local/bin/, as writeable by the default user. (those are the usual places for user apps in BSD). Note that Mac OS X also has some of those folders and they have the permissions set correctly. /Applications is where users on Mac OS X go for their apps. Making it writeable by a user that has admin privs is not a good idea. It basically breaks the BSD (and most all Unix/Linux) filesystem security model.

The argument is whether OS X is more secure than Windows. Running an executable on Windows is as easy as opening an email. Running an executable on OS X requires significantly more work. This makes OS X more secure.

The argument has nothing to do with Windows. If Windows didn't exist the current security model for Mac OS X is still weak. It is two mouseclicks to run an attached executeable in Mac OS X. I don't call that "significantly more work". That attached app will run with the permissions of the user that clicked on it. If that user is the admin user there is very little that attached app can't do. It could drp in a keystroke logger, snoop around the system gathering useful stuff, and display a nice pic of some pop star... it can do all sorts of stuff. It can even replace a "trusted" app in /Applications one that behaves very much like the original but some extra stuff too.

The point I was trying to make earlier (and I think graymalkin actually made) is that to install an executable on OS X requires a user to take purposeful steps, which is enough to prevent Windows-style email attacks (which require absolutely no extra action on the part of the user). But if I download a program, I'm going to take the steps necessary to install it (including typing a password), regardless of whether it turns out to be a "rogue app". And I may end up permanently escalating my privileges because I get annoyed with typing passwords all the time. Then we have a real problem.

Yeah those are problems. Would be nice if people could be educated to run new apps in a "jail" or just install them to ~/Applications first to try them out.

I make no apologies for how Windows does stuff... again it is irrelevant.

Further, if I have to type a password for my every move, then the significance of typing a password is lost. I'm more likely to not look at the thing that's asking for the password, and perhaps even willingly type it for the "rogue app" because I'm so used to typing it at all times.

Yes I agree that can also be a problem... especially for the home user that installs apps all the time. But do people really install that many apps all the time? Does the download (sometimes requiring the user type in all sorts of information), the unpacking, the install routine (which is quite variable on Mac OS X). What would be the difference of typing in one password be to all that? Too much? Some apps already seem to ask for a password before they install. I have seen it said that is because the permissions on /Applications is "broken" somewhere and one should run the Repair Permissions Utility.... then everything will be fine and the app will install WITHOUT requiring a password.

Fair enough. We all have improvements we'd like to see, and OS X still has work to be done. But compare these complaints to what we might say of Windows:

-I don't like how Windows shares C$ and IPC$ by default
-I don't like how Windows runs applications with full privileges from email
-Windows shouldn't make the local user root by default

I mean, these types of improvements are in a completely different class than changing the default permissions of the users home directory.

I really REALLY don't care what Windows does. I don't use Windows because of these problems (and many other reasons). I would like to see Mac OS X improve to the point that there is just isn't anything to compare.

Ultimately, I maintain that an "out-of-the-box" OS X machine, though not completely secure, is more secure than a Windows machine in the default configuration.

I agree. But I also maintain that it is far less secure than it can be.

[Link]

UT, I take it you're EXTREMELY concerned about security, man.

I tell ya what, how about we lock you in the closet? It's secure! I promise! Nobody will bug you to fix their computer in there..

There's some towels on the floor so it's comfy too

[qyn]

Originally posted by utidjian:
As I said before... Windows is irrelevant to this discussion about Mac OS X security.

The question this thread was asking is "Should we be quiet about Mac security? or tout it?" This is a question about marketing, and Windows is very relevant to that discussion.

I think I understand your position and you understand mine. You raise valid points about the security of OS X in a perfect world. I'm not convinced of their applicability to a consumer OS. Beyond that, I think we'll just have to agree to disagree.

[Person Man]

Originally posted by utidjian:

Mac OS X should force users to choose a reasonably strong password. Many versions of Unix already do this. Yes, this can be frustrating for the user. It is much more frustrating to have a compromised account though.

Mac OS X shouldn't FORCE anyone to do anything. You have to realize that Apple has made some compromises because you have end users using the system too, not just fully qualified system administrators.

As a rather extreme example of why OS X shouldn't force a "reasonably strong" password on someone, consider a computer that is not connected to the internet, but is used by a 4 year old for educational software. You try teaching little Susie to type "c0Mpu73R%$[" (or better yet, remember the "code" for a passphrase-- i.e. "If You're Not Absolutely Sure, You're Absolutely Dead" (From the Steve Irwin FedEx Commercial) encoded as !yN@$yaD.) In this case (computer not connected to internet), wouldn't it be a lot easier to let Susie type "doll" for her password? (or better yet, not even need one?)

[Graymalkin]

Strong passwords should always be a recommendation on consumer systems, not requirements. The simplest way for multiple users to share a computer but have different preferences is to have multiple user accounts. Say my girlfriend and I share a Mac. I like the Dock on the left side of the screen and my Boba Fett background image with Safari as my default browser. My girlfriend hates Star Wars and likes her Dock on the bottom of the screen and uses Camino. Instead of us futzing with each other's preferences we can instead create two users with no password and enable Fast User Switching. If OSX enforced a strong password on us this would be much less convenient.

I don't know where the assumption OSX breaks Unix conventions comes from. A properly managed Unix system should have an admin group with write access to local resources such as /opt and /usr/local just as OSX does with /Applications. It wouldn't make a lot of sense for a multi-user system to require the root password to be known to all the system administrators both high and low level. Using admin groups allows for system management in a secure fashion. The Admin users in OSX are an implementation of this idea. It isn't the most super secure system management scheme but OSX isn't meant to be super secure out of the box, instead it is meant to be usable and moderately secure.

While I think it ought to suggest with a bit more vitriol the creation and use of non-Admin users I don't think the current implementation is necessarily broken. The Admin group doesn't have system level access nor can they by default access most of the subdirectories owned by other users. Running around as an Admin allows for the installation of "rogue apps" in /Applications and the futzifying of your own directory but the rest of the system will remain largely intact without password access.

It all really comes down to a compromise between usability and security. Without managed resources (LDAP and Kerberos authentication) it is difficult to make a truly secure and easy to use system. By default OSX is meant to be usable by computer novices as well as experts. Much emphasis is put on backing up important files and all Macs now come with CD writers. As long as your personal files are backed up a comrpomised system is a matter of inconvenience rather than lost work. Rogue apps will run anywhere and a lot can be done to destroy an OSX system even iff the /Applications directory's permissions were set to 0755.

[utidjian]

Originally posted by Person Man:
Mac OS X shouldn't FORCE anyone to do anything. You have to realize that Apple has made some compromises because you have end users using the system too, not just fully qualified system administrators.

As a rather extreme example of why OS X shouldn't force a "reasonably strong" password on someone, consider a computer that is not connected to the internet, but is used by a 4 year old for educational software. You try teaching little Susie to type "c0Mpu73R%$[" (or better yet, remember the "code" for a passphrase-- i.e. "If You're Not Absolutely Sure, You're Absolutely Dead" (From the Steve Irwin FedEx Commercial) encoded as !yN@$yaD.) In this case (computer not connected to internet), wouldn't it be a lot easier to let Susie type "doll" for her password? (or better yet, not even need one?)

Sure. Such a system is setup in what is sometimes called "kiosk mode". You may see systems setup this way at an Apple Store or at a grade school. I haven't been to a pre-school in a long time myself so I don't know how many 4 year olds actually use computers. I suppose some of the ones that I have seen at Apple Stores are as you as 4... never asked. That 4 year old is hardly likely to be reading emails (if he/she can read) let alone write any. They certainly have no business installing applications in the /Applications folder.

Kiosk mode can also be used for 40 year olds... with no loss of functionality for their uses. However if they are going to create and use data that they want to protect from others they will need to have a userid and password.

[Graymalkin]

Additional password security is only going to be effective on larger systems with lots of users. Strong passwords are important when you've got 50 users on a four way Unix server, they're far less important on the home iMac. Trying to protect users from themselves only does a modicum of good because as long as they know the admin password they will continue to do unsafe things. An extra password required to drag an application to the /Applications folder isn't going to stop anyone who knows the password, vis � vis anyone who can log in as an admin user.

[Richard Edgar]

As long as your personal files are backed up a comrpomised system is a matter of inconvenience rather than lost work

That isn't exactly correct. Any backups from the date of infection must be regarded as suspect. For example, a piece of malware could scan files for text strings and 'helpfully' switch letters around. If it does that for long enough, then all of your backups will be useless.

Some more general thoughts: security in OSX is probably generally better than under Windows (although I'm not certain this would be the case if the security model Microsoft claims for NT was implemented properly). However, no system can be secure in the face of determined stupidity by its users. A recent article on The Register claimed that some recent trojans required users to extract the trojan from an encrypted zip file attached to a mail (the password was in the message). What can any OS do against that sort of behaviour? Once any program is running that shouldn't be running, acquisition of extra priviledges is generally possible - be the OS Unix or Windows.

[Love Calm Quiet]

Can somebody help me understand why it's a big deal to have access to the Applications folder. After all, an application *can* be stored somewhere else and still run, can't it? Is a "rogue" app somehow more dangerous there than elsewhere?

About "the 4-year-olds" and security. Sure we'd like naive users (4 or 84 years) to be able to use their Mac without undue complexity... If they're connected to the web with a cable modem is still is in *everyone's interest* (i.e., the whole public's) that they cannot too easily let their machine (or even their user on the machine) become the equivalent of the Windows "zombied" machine that get used as spam relays, etc. How does that get balance against ease of use? Just wondering.... how to balance the two concerns.

[Millennium]

Originally posted by Person Man:
Mac OS X shouldn't FORCE anyone to do anything.

That's where you're wrong. Forcing a reasonable degree of security is not only desirable, but necessary, because it's been proven time and again that security-wise, the weakest part of any system is the user. And in an age of distributed spambots, even the security of a child's first computer matters.

This said, there is no need to be insane about it. Indeed, forcing extreme degrees of password security has been shown to do more harm than good, because users have a greater tendency to write passwords down when you make them too difficult to guess.

But in any case, the very least Apple should do is scan each password through its spelling dictionaries and disallow anything which matches. It should also disallow matches with the longname or shortname. These two simple steps would make for much stronger passwords, while remaining reasonably lenient.

[Millennium]

Originally posted by Graymalkin:
As long as your personal files are backed up a comrpomised system is a matter of inconvenience rather than lost work.

Are you really that naive, to think that this is the only problem with a hacked machine? You must realize that only the 1337 skr1pt k1ddi3z want to break the machines they compromise, and the Mac will never be a major target for these. Most hackers want the machine to keep running, and the data to remain intact, for as long as possible. Compromised machines are, after all, much more useful alive than dead.

Problem One, of course, is that someone else has access to your personal data. Depending on what data you have stored on a compromised machine, this can range in severity from "minor nuisance" to "life-threatening". For most people nowadays, it's much closer to the latter end of the scale, even though there are still relatively few people actually at that endpoint.

Problem Two is that someone else is using your machine for Bad Stuff. While you are generally not considered legally responsible for this type of thing (and that is good), there remains a moral responsibility to ensure that your machine is not used for nefarious purposes.

Problem Three: no hacker in his right mind uses his own machine to hack stuff. Unless you've been hacked by someone with a very young personal network, you are probably going to be compromised by a hacker using not his own machine, but someone else's machine that he has already hacked. Your machine, in turn, will be used to hack others' machines, and it will look like you did it. If that doesn't scare you then you're either very stupid or very overconfident.

No. Reasonable password security should be forced. There is no need to go overboard, but there is a minimum standard which must be observed.

[utidjian]

I think that part of the main difficulty I am having getting my point across has two sides to it.

1. I come from more of a Unix background than Mac/Windows. A major part of the Unix security model is the "Principle of Least Privilege". This means that ANY user (even root in some cases) should have only the rights neccessary in order to do their job. A key part PoLP is a clear separation between types of users (regular, admin, root...). Call it the "Separation of Powers" (SoP) if you will. In a Unix world it is desireable that a user with elevated privileges is always aware of it. Unix sees the tasks of administering a system as separate from using a system.

There are lots of schemes to enforce this concept... ranging from popup dialogs to chroot jails to detailed configurations in /etc/sudoers and others. Some are pretty easy and transparent BUT all of them try to, at some level, to remind the person that is admin that they are indeed in an admin mode. On the systems I administer I have created separate admin accounts. I use the string "admin" somewhere in the username for that account. The user "utidjian" is NEVER an admin of anything other than his home folder and prefs.

My Unix background has mainly been in an academic setting (Berkeley, Rutgers, NJIT, RCNJ) and a few years in a corporate setting. In the academic setting there are lots of users that one never even knows or meets. PoLP and SoP are essential concepts to running a reasonably secure system for all the users in such a setting.

2. Most users have a Mac/Windows/desktop background. The whole concept of security, userids and passwords, privileges and rights, system administration are completely foreign or not well understood. Before Mac OS X there was no real concept of "admin user" there was just "using the computer". I think that most desktop users today are, at least, familiar with the idea of userids and passwords for all the things they have are forced to use authentication for (email, banking, some games, unlocking of some documents). In many cases, for ease-of-use these authentication schemes are automated ("Remember my login" checkboxes). It is no longer completely foreign to them. Though the concept of PoLP and SoP are.

With the connectivity and power of computers and current OSes and the amount of important data that is stored on them I think it is important that users from side 2. should, at the very least, understand side 1.

Perhaps users need more time to learn and understand the concepts of side 1. But, I think, all users that own, operate, and administer their own computers should move to side 1. The way I see it, sooner or later, they will have to. This may be difficult and take time but just as we have learned not to give out our credit card numbers (and similar things) to just anyone we have to learn to be more careful with how we use computers.

[utidjian]

On weak passwords:

It is amazing to me what people will choose for a userid and what they will choose for a password. I have users that want a userid like:

M@x0\/3rdR1\/3

and then choose a password like

jockstrap

This example would be far better if the userid and password were reversed.

It really isn't that hard to come up with a decent one. Just think of something that you like or do or have done and make up a little phrase or word were you can map in some other character. For example:

j0ck5tr@p

is far far better than the original.

If you are still using 10.2 or earlier or you haven't changed all your passwords to shadow passwords yet try running John the Ripper on the resul from "nidump passwd ." You may be amazed at the results and how quickly it will extract the plain text passwords for you.

If you are the admin of system with a lot of users you should talk to those users that have easily crackable passwords and get them to change them. If you are not admin of the system that you get the passwd list from, do the right thing and show the admin of that system your results. Better yet... update all systems to 10.3.x and get all passwords changed over to the shadow type.

John the Ripper is available from:
http://www.openwall.com/john/
in both binary and source for Mac OS X.

Remember... if you can easily crack the passwords... so can someone else.

[Person Man]

Originally posted by Millennium:
That's where you're wrong. Forcing a reasonable degree of security is not only desirable, but necessary, because it's been proven time and again that security-wise, the weakest part of any system is the user. And in an age of distributed spambots, even the security of a child's first computer matters.

This said, there is no need to be insane about it. Indeed, forcing extreme degrees of password security has been shown to do more harm than good, because users have a greater tendency to write passwords down when you make them too difficult to guess.

But in any case, the very least Apple should do is scan each password through its spelling dictionaries and disallow anything which matches. It should also disallow matches with the longname or shortname. These two simple steps would make for much stronger passwords, while remaining reasonably lenient.

I still don't think people should be FORCED. Apple shouldn't disallow anything (i.e. let people have unsecure passwords if they want to... it's their machine after all, and they should be able to do what they want with it).

The least Apple could do is scan each password as you suggested above and then display a warning that the password is not very secure, and offer to let the user change it to something that is more secure (display hints on how to do it), or accept the responsibility for the not-so-secure password and use that instead.

[Person Man]

Originally posted by utidjian:
Sure. Such a system is setup in what is sometimes called "kiosk mode". You may see systems setup this way at an Apple Store or at a grade school. I haven't been to a pre-school in a long time myself so I don't know how many 4 year olds actually use computers. I suppose some of the ones that I have seen at Apple Stores are as you as 4... never asked. That 4 year old is hardly likely to be reading emails (if he/she can read) let alone write any. They certainly have no business installing applications in the /Applications folder.

Kiosk mode can also be used for 40 year olds... with no loss of functionality for their uses. However if they are going to create and use data that they want to protect from others they will need to have a userid and password.

No, it's not called "kiosk" mode, if it is not set up as such. I'm talking a child set up as a "regular" unprivileged user, with no password, and no automatic launching software (i.e. the environment that is default in OS X for a non-admin user).

[utidjian]

Originally posted by Person Man:
No, it's not called "kiosk" mode, if it is not set up as such. I'm talking a child set up as a "regular" unprivileged user, with no password, and no automatic launching software (i.e. the environment that is default in OS X for a non-admin user).

And this hypothetical 4 year old is going to type in their userid and just hit enter at the password prompt? Or does the machine just boot up with that 4 year user logged in? In which case how is that different from "kiosk mode" where everyone is that user? (except, of course the admin).

I have very little problem with how regular (I think Apple calls them "Standard") users are set up in OSX except for being able to read any other users home folder. The fact that a regular user is usually only authorized for read and write to ~/ and /Users/Shared/ is fine with me. Though sometimes that gets a little broken (hence the need for Repair Permissions Utils).

My problem is with (in case you haven't caught on yet) the admin user logging on to the admin account as if he/she was logging in as a regular user. I am not talking about 4 year old admins.

Perhaps it might be a good idea to teach a 4 year old child to type in some sort of secret as well as teaching them to type their userid. I mean while you are at it... just a thought.

Note also that Panther is pretty insistent about adding a password. Too bad it isn't as insistent about adding a good password.

[Person Man]

Originally posted by utidjian:
And this hypothetical 4 year old is going to type in their userid and just hit enter at the password prompt? Or does the machine just boot up with that 4 year user logged in? In which case how is that different from "kiosk mode" where everyone is that user? (except, of course the admin).

No, the computer would be set up with the list of names displayed on screen and so all she would have to do is click on her name, and maybe press return for the blank password (I've never set up an account without a password so I don't know how OS X would react in that situation).

I have very little problem with how regular (I think Apple calls them "Standard") users are set up in OSX except for being able to read any other users home folder. The fact that a regular user is usually only authorized for read and write to ~/ and /Users/Shared/ is fine with me. Though sometimes that gets a little broken (hence the need for Repair Permissions Utils).

I agree that regular users shouldn't even be able to open the folders of other users even if they can't open their documents. Other users' files and home folders should be entirely off limits, period, unless the user is given explicit permission to open them. But even then, setting up a group folder and putting people in groups would be a better idea anyway.

My problem is with (in case you haven't caught on yet) the admin user logging on to the admin account as if he/she was logging in as a regular user. I am not talking about 4 year old admins.

Perhaps it might be a good idea to teach a 4 year old child to type in some sort of secret as well as teaching them to type their userid. I mean while you are at it... just a thought.

Well, different strokes for different folks, I guess. Your point of view makes more sense for a server or even a workstation at a business, but for the average home user, Apple has come up with a fairly workable compromise in allowing an admin user to log in as a regular user. Even so, you still have some idiots insisting on enabling the root user and using it instead of the admin account.

My mother is an example of why the compromise was put in place. When I set her up with Mac OS X for the first time, she asked, "Why should I have to have a password anyway?" She wasn't pleased with the idea, so the computer is set up to automatically log her in as the administrator. She would have gone absolutely ballistic if I had set her up as a regular user and told her in order to install applications she would have to log in to a totally separate account. Even though she doesn't install things on a daily basis.

Note also that Panther is pretty insistent about adding a password. Too bad it isn't as insistent about adding a good password.

Like I said, I've never tried to set up an account without a password. I do think OS X should at least tell you that your password is "not-so-good" and give you the opportunity to use a stronger one, but the user shouldn't be forced to do so. Yes, you would still have people using insecure passwords, but I'd be willing to bet that many people would use more secure ones if prompted by the OS.

In fact, the keychain application even has a basic password checker in it that tells you, graphically and numerically how strong the password is and even gives some hints as to how you can make it stronger. Apple should include it as part of the initial setup process.

Note that I wouldn't be opposed to Apple forcing strong passwords in OS X Server, however. Client should not force anyone to do anything, but it should make suggestions.

[Person Man]

Originally posted by utidjian:
On weak passwords:

It is amazing to me what people will choose for a userid and what they will choose for a password. I have users that want a userid like:

M@x0\/3rdR1\/3

and then choose a password like

jockstrap

LOL

If you are still using 10.2 or earlier or you haven't changed all your passwords to shadow passwords yet try running John the Ripper on the resul from "nidump passwd ." You may be amazed at the results and how quickly it will extract the plain text passwords for you.

If you are the admin of system with a lot of users you should talk to those users that have easily crackable passwords and get them to change them. If you are not admin of the system that you get the passwd list from, do the right thing and show the admin of that system your results. Better yet... update all systems to 10.3.x and get all passwords changed over to the shadow type.

John the Ripper is available from:
http://www.openwall.com/john/
in both binary and source for Mac OS X.

Remember... if you can easily crack the passwords... so can someone else.

If you're the admin of the system, yes, great idea. If you're not the admin of the system, running John the Ripper, even with the best of intentions, could get you in trouble with the system administrator, or worse, fired for inappropriate use of the system.

[sniffer]

Originally posted by utidjian:

Note also that Panther is pretty insistent about adding a password. Too bad it isn't as insistent about adding a good password.

I agree. Heh.. I really think Apple could tout security.

I sat up my XP box recently, added an extra account for a family member, and this is how XP Pro comes by default:

No firewall enabled (same thing for os x IIRC), no passwords on the users, both users have Administrator priviligies (not to far from being root in os x), and everyone have access to everyones document folder. What the hell? Anyway, it's not to hard to configure XP so it becomes quite secure, but most people don't get these things unfortunately. Oh well

[Graymalkin]

Originally posted by Millennium:
Are you really that naive, to think that this is the only problem with a hacked machine?

While your points are valid you've got to remember that a skilled and determined hacker is no more going to be stopped by a strong password than they will be by hiding your credit card numbers in ~/.SecretNumbers. Turning a Linux or OSX machine into a zombie by means of a network attack is fairly difficult. Remote root exploits take the form of bug exploits rather than policy exploits typically.

Local exploits are possible but actually require physical access to the machine. If I've got physical access to your machine your strong password isn't going to stop me from doing anything I want with your system.

Only bitter revenge makes rooting and zombie'ing an OSX machine worth the time and effort it would take. Strong passwords are not likely to help anyone in that situation. As such the OS forcing you to use megastrong passwords is just going to be inconvenient to users who paid good money for it. The OS should warn you if you have a relatively insecure password and tell you if you turn file sharing on you stand the chance of allowing people full access to your files if they guess it. That is a bit different than shutting itself down and refusing to run until you've graduated with a BS in computer engineering.

[qyn]

Originally posted by Graymalkin:
Local exploits are possible but actually require physical access to the machine.

This isn't really true. Local exploits are possible if (for example) someone manages to buffer overflow some service (sendmail anyone?) and then have that service execute code.

As utidjian indicated, this could allow an attacker to dump and crack the passwd file.

But the thing about OS X (in the case of sendmail) is that there are very few machines that are actually running sendmail, since it's turned off by default and isn't trivial to turn on.

Quoth CERT: "It should be noted that sendmail is not enabled by default on Mac OS X, so only those systems which have explicitly enabled it are susceptible to the vulnerability." Contrast this to their notes about Red Hat, Debian, or BSD. (I'm looking at http://www.cert.org/advisories/CA-2003-07.html).

Not that I disagree in general with what graymalkin is saying about passwords...

[utidjian]

Originally posted by Person Man:
No, the computer would be set up with the list of names displayed on screen and so all she would have to do is click on her name, and maybe press return for the blank password (I've never set up an account without a password so I don't know how OS X would react in that situation).

OK so if this is a machine at home and she is the only child that would make sense (kinda). In a pre-school where there might be many 4 year old boys and girls... there is nothing to keep them separate. How is this effectively different than kiosk mode if there is more than one child user?

Well, different strokes for different folks, I guess. Your point of view makes more sense for a server or even a workstation at a business, but for the average home user, Apple has come up with a fairly workable compromise in allowing an admin user to log in as a regular user. Even so, you still have some idiots insisting on enabling the root user and using it instead of the admin account.

The admin account is only once removed from root.
The admin user is still a user where the consequences of their actions can affect all users of that system. That person should not be logged in as that user all the time they are just using the system.

My mother is an example of why the compromise was put in place. When I set her up with Mac OS X for the first time, she asked, "Why should I have to have a password anyway?" She wasn't pleased with the idea, so the computer is set up to automatically log her in as the administrator. She would have gone absolutely ballistic if I had set her up as a regular user and told her in order to install applications she would have to log in to a totally separate account. Even though she doesn't install things on a daily basis.

Yeah this is a problem. Mothers and fathers are MUCH harder to educate than 4 year olds. I have seen a proposal that the user who has admin "access" just be a regular user most of the time. When something that requires full admin rights they are FUSed to the "admin" user. As the admin user stuff like most of the iApps don't work. They go in there... get the job done... and get out. Back to using the system.
This scheme (just like sudo) can have a timeout of, say, 5 minutes between these sessions before they are asked for a password again.

Do you get the picture? You doodle along doing whatever it is you do as a regular user. You decide to install some new software. Bink the FUS dialog pops up (you log in as admin) and it switches to that user. You finish... but since you are in a limited environment and want to get back to what you were doing you click right side of the menu bar where it says admin, the only other user you see is your userid and the login window as options. You click on your userid and there you are back where you left off. For another 5 minutes you can just click on the FUS thingy in the menu bar and switch back to admin if you need to. If you are in the admin user account (say you just FUSed to it) then you can stay there as long as you like. You won't want to though... not unless you have a lot of admin type stuff to do.

You want to drag and drop an app on to /Applications the FUS dialog pops up.

Personally I am a bit confused about how apps install in Mac OS X. Some seem to start out with an installer (as in OS9) and one goes though a bunch of button clicking and whatnot... no dragging and dropping to the /Applications required.

Some seem to unpack and then need to be dragged and dropped.

Most seem to leave two or three icons on the desktop... gets messy. Some of the icons look like a box some look like a usb floppy drive some look like a disk on a sheet of paper. What does your mom do with all of that junk?

I also think Mac OS X needs a better and cleaner package management system. Doesn't have to be as fancy as fink. Would be nice to have something that doesn't clutter up the desktop with a bunch of icons. But since we are talking about security... the package should be "signed" by the maker (MD5, GPG, etc). So you know it came from them and isn't corrupted in any way. If it doesn't pass the tests the system should refuse to install it. Fink does this.

Like I said, I've never tried to set up an account without a password. I do think OS X should at least tell you that your password is "not-so-good" and give you the opportunity to use a stronger one, but the user shouldn't be forced to do so. Yes, you would still have people using insecure passwords, but I'd be willing to bet that many people would use more secure ones if prompted by the OS.

We can only hope. Would take some fairly interesting engineering to get them too though. I simply lock the accounts of the easy guesses even after they have been prompted to choose a better one. They learn.

In fact, the keychain application even has a basic password checker in it that tells you, graphically and numerically how strong the password is and even gives some hints as to how you can make it stronger. Apple should include it as part of the initial setup process.

Yep, I agree.

BTW... I was playing with fixing the un-shadowed passwords on my system that was upgraded from 10.2. Some will shadow and some will not. Seems kinda buggy.

I was also playing with enabling and disabling the root user. I read somewhere that one can enable the root user. Give root a password and then disable root again. This would make it so someone could not walk by a machine that is unattended (and the user is the admin) and the passer by could not enable root without the root password. Guess what... no I can't DISable root. It says it is disabled but I can still log in as root, I can still ssh in as root.... seems like another bug somewhere.

Note that I wouldn't be opposed to Apple forcing strong passwords in OS X Server, however. Client should not force anyone to do anything, but it should make suggestions.

Well um... the client forces you to use sudo for admin types of things on the CLI... why not the equivalent in the GUI? Sometimes it does. There is an option somwhere that requires that one authenticate to make any changes via System Prefs that would require admin or root privs. I always set that to on.

[utidjian]

Originally posted by Person Man:
If you're the admin of the system, yes, great idea. If you're not the admin of the system, running John the Ripper, even with the best of intentions, could get you in trouble with the system administrator, or worse, fired for inappropriate use of the system.

Don't run it on your employers system. There is nothing illegal about a regular user running "nidump passwd . >passes.txt" and sending that file to your own laptop for grinding. At least Apple doesn't seem to think so.

[utidjian]

Originally posted by qyn:
This isn't really true. Local exploits are possible if (for example) someone manages to buffer overflow some service (sendmail anyone?) and then have that service execute code.

As utidjian indicated, this could allow an attacker to dump and crack the passwd file.

But the thing about OS X (in the case of sendmail) is that there are very few machines that are actually running sendmail, since it's turned off by default and isn't trivial to turn on.

Quoth CERT: "It should be noted that sendmail is not enabled by default on Mac OS X, so only those systems which have explicitly enabled it are susceptible to the vulnerability." Contrast this to their notes about Red Hat, Debian, or BSD. (I'm looking at http://www.cert.org/advisories/CA-2003-07.html).

Not that I disagree in general with what graymalkin is saying about passwords...

What CERT didn't tell you in their notes about Red Hat (can't speak for the others) is that even though sendmail is turned on by default... it is ONLY listening on 127.0.0.1 (to itself). So unless someone went to the trouble of enabling it to listen to the external interface it was not a problem for default installations of Red Hat.

[qyn]

Originally posted by utidjian:
OK so if this is a machine at home and she is the only child that would make sense (kinda).

OK, I'm apologize to all involved parties, but the example of the 4-year-old is kind of ridiculous. Is this how we reason about security?

Most seem to leave two or three icons on the desktop... gets messy. Some of the icons look like a box some look like a usb floppy drive some look like a disk on a sheet of paper. What does your mom do with all of that junk?

This makes me question your experience with OS X. First off, most installations do not leave any files on your desktop. If you have your default download directory set for the desktop, then yes, some files will go there. This has nothing to do with installs. Second, the "disk on a sheet of paper" is a disk image, which when mounted looks like a "usb floppy drive". Perhaps you were being deliberately flip to make a point, but I'm not sure what that point had to do with the security of OS X.

I also think Mac OS X needs a better and cleaner package management system.

Agreed (and having a facility for package signatures would be a very welcome feature). But I think this is largely in the hands of the developers. This is why you have drag-n-drop installations versus installers versus whatever other scheme they come up with. I personally hate installers, but Apple (for one) seems to prefer them because they're easier on the newbie.

In any case, I think fixating on this app install issue is missing the bigger picture. I run many apps from my download directory (first time trial, etc), and many apps I run off the disk image forever. Not everyone will do this of course, but it shows that it would be trivial to circumvent the protections on the /App dir.

Many (most?) of the critical functions are protected by password anyway, even for admin users. There are cases where critical functions are not protected by password, but this is more of an oversight than a flaw in the basic security model. For the reasons stated above, I don't see the /App folder as a critical function. So while your technique of temporarily elevating privileges has merit, I think it's too much for a home user.

So unless someone went to the trouble of enabling it to listen to the external interface it was not a problem for default installations of Red Hat.

Yeah, it may not have been a problem for any of the Linux/BSD systems. It was a cheap shot at Linux/BSD that I really can't back up.

[Richard Edgar]

Indeed, forcing extreme degrees of password security has been shown to do more harm than good, because users have a greater tendency to write passwords down when you make them too difficult to guess

Again, that will depend on the situation. For a business (where the greatest threat is actually insiders) that's certainly true. For home users, the biggest threat is typically the remote hacker.... in which case having the password on a post-it note attached to the screen isn't so much of a problem.

Problem Two is that someone else is using your machine for Bad Stuff. While you are generally not considered legally responsible for this type of thing (and that is good)

No it's not good. In many ways, that's the problem. People can just say "Well I don't know anything about computers" and get away with criminal irresponsibility (at the least). If anyone is sitting in front of a computer, then that computer can do nothing without their permission (ultimately, they can pull the power cord). Therefore, they have responsibility for what that computer does. No ifs, buts or maybes.

A major part of the Unix security model is the "Principle of Least Privilege". This means that ANY user (even root in some cases) should have only the rights neccessary in order to do their job

Which is why the backup script on a Unix system has to be able to delete any file? Everything isn't fine on the Unix side of the fence either - Unix implements the minimal necessary to make a reasonable multiuser system. Indeed, I believe that this is one area where NT should be better - it is supposed to have finer-grained control. It doesn't - AFAICT because setting such things up properly takes slightly more effort than most people are prepared to put in... so Microsoft made it possible to bypass the system. Why does NT have its graphics drivers in the kernel? Because their customers wanted to be able to play games.

Apple shouldn't disallow anything (i.e. let people have unsecure passwords if they want to... it's their machine after all, and they should be able to do what they want with it)

Presumably you also don't expect cars on the road around you to have well maintained brakes?

[JLL]

Originally posted by utidjian:
But since we are talking about security... the package should be "signed" by the maker (MD5, GPG, etc). So you know it came from them and isn't corrupted in any way. If it doesn't pass the tests the system should refuse to install it. Fink does this.

And so does Software Update.

Originally posted by utidjian:
I was also playing with enabling and disabling the root user. I read somewhere that one can enable the root user. Give root a password and then disable root again. This would make it so someone could not walk by a machine that is unattended (and the user is the admin)

You need to know an admin password to enable root - you can't just walk by an unattended machine logged in as an admin and enable root.

Originally posted by utidjian:
Guess what... no I can't DISable root. It says it is disabled but I can still log in as root, I can still ssh in as root.... seems like another bug somewhere.

Must be a bug in your system. A disabled root (which is disabled by default) is a disabled root. You can't su root, log in as root or anything else.

Perhaps it's a bug when you have enabled root once, since root then has a password. On a default Mac OS X install you can't log in as root (you haven't even given root a password).

The only thing you can do is sudo.

[qyn]

Originally posted by Richard Edgar:
Presumably you also don't expect cars on the road around you to have well maintained brakes?

That's an interesting point. All users of the internet should have internet insurance so that when they are liable for damages, their insurance company will pay out. Of course, premiums will be based on the strength of the password, among other things.

[Richard Edgar]

All users of the internet should have internet insurance so that when they are liable for damages, their insurance company will pay out

Insurance shouldn't be compulsory - liability should be. Of course there are certain international issues, but idiocy is too.

[utidjian]

Originally posted by JLL:
And so does Software Update.

Which is fine except... it only applies to softwareupdate and that is rather limited. My suggestions was for a general installer not just softwareupdate and fink.... so that it could be a requirement for all software.

You need to know an admin password to enable root - you can't just walk by an unattended machine logged in as an admin and enable root.

It was here I read about it:
http://www.princeton.edu/~psg/unix/o...ty.html#oneone

That was to lock out other admins from changing it and in case someone got the admin password.

Must be a bug in your system. A disabled root (which is disabled by default) is a disabled root. You can't su root, log in as root or anything else.

Well I tried it on another system that is all updated as of this time. I enabled root. Then tried to disable it... Under the Security menu in NetInfo Manager all I have is Authenticate, Change Root Password (which is greyed out) and Enable Root User. On my other system at least Enable.. toggled to Disable, even though it didn't work. So on this system where root seems to be disabled it is really enabled (I can su -, I can ssh in as root, I can log in as root). So far that is two out of two systems that are basically stock Mac OS X. I will try another one today. Perhaps I have to Repair Permissions or something (sigh).

Perhaps it's a bug when you have enabled root once, since root then has a password. On a default Mac OS X install you can't log in as root (you haven't even given root a password).

The only thing you can do is sudo.

Yeah it seems to be a bug so far. Will try one more machine and if I get 3 for 3 I will report it to Apple.

[utidjian]

Originally posted by Richard Edgar:

Which is why the backup script on a Unix system has to be able to delete any file?

What backup script is this?

In my experience, backup scripts/programs can copy a filesystem or set of files from a filesystem to another filesystem. This behaviour is usually desireable.
A restore script/program will do the reverse. This is also desireable.
In the scripts that I write for backups and restores there are "sanity" checks throughout so I can be sure that I am writing to the correct place and restoring from the correct place... otherwise the script fails.

[ism]

OK reading this is interesting, how would any of you recommend moving from an admin account to a normal user account?

I.e. basically I want my current (default first created) admin account just to be a normal account (I don't want to loose all my preferences, username, etc), and a fresh account to be an admin one