[zottel]

Originally Posted by dangerous

MOAB #15 is an interesting one. That is really crazy and I think Apple dropped the ball here. However apart from that (which still depends on you explicitly running some malware application) I'm going to continue to disagree (and maybe agree to disagree as OG forums is not really the place for this... maybe we should take it to MacNN). Talking about "giving an application permission" though, well it just depends on how you think about it. Windows is mega dangerous because it will run stuff without asking you. On a Mac, things will only run if I run them. By running them, I give them permission to do what they want. I don't run software I don't trust on my machine. Running as a normal user wouldn't help because if I run something then I have already decided to trust that application and so if it asked for a username and password I would gladly hand it over.

The point you forget is buffer overflows. Such flaws are found all the time, and in software from Apple, too, of course. Say someone finds a tricky way to produce a buffer overflow in Mail.app by sending you a faulty jpeg. In some circumstances he will be able to make Mail (or OW, or iChat or whatever program you use that works with data that comes from the net) execute code he has inserted into that jpeg, that iChat message, that Word document or whatever. This code will run as admin in your system, and you didn't intend to execute it at all.

Just to clarify for everyone, a short description of how buffer overflow exploits roughly work: If there is a (wrong) way to format data in a file that the application programmers didn't think of, and the application can thus be tricked to read in more information than it thinks it reads, this additional information will be randomly written to the memory. It can be possible to execute this information as code later on. This is not easy, of course, and in many cases the application will just crash; no further harm done. On the other hand, it's far from impossible.

Bugs like that are quite common. Do you read the descriptions of Apple updates? Did you notice how often some sentences like "... could possibly lead to execution of arbitrary code" are to be found there? These are the fixes to the bugs we are talking about here.

This can also happen to network daemons, of course, which have to run as root, in most cases. If that happens ... well, shit happens. But that's a point I just can't guard my system against if I want to run those daemons (other than by always keeping it up to date, so that bugs of that kind are fixed as quickly as possible). But I like keeping the risk small by not taking it where I don't have to.

An interesting thing you might not have considered. I run as an admin user, I install Omniweb by dragging it to my applications folder, update by running the update. It's all smooth. You install it by dragging and authenticating, and update by running the update and entering your admin username and password into Omniweb's interface. Your copy of Omniweb now, if it was evil, has an admin password (with sudo privileges) and can do much more on your system than it can on mine.

Well, at this point I'm on the same trust level as you are. Or better, you're right, I trust installers even more than you do. But just as you do, I don't execute soft I don't trust. And if some app suddenly wants to write to directories I didn't expect it to, I'm warned by the popup. (Though I'd REALLY appreciate if that popup was a bit more precise on what the app is intending to do ...)

Zottel's chown could also be dangerous. It does not check rights. Let's say there is a folder to which I, another user on Zottel's machine, have write privileges to. Any folder chmodded to 777 would do. Looking in my Applications folder, Filemaker, Toast, Zend and a few others have folders with 777 privileges. Now if I was a user on Zottel's machine, and I saw his crontab was chowning everything to root:admin, I could just do the MOAB #15 thing without even being an admin user. I create a script (even just a file containing the single word "zsh" or "bash" to give me a shell), chmod +s the file and then wait for Zottel's cronjob to run. Now I have a root shell!

Well—there are no directories inside /Applications on my system to which any user but the admin user has write priviledges to, of course. :-) Anything else would be ridiculous.

And, btw, suid doesn't work on scripts on most (all?) unix systems, for obvious reasons (they are easily altered to do something that wasn't intended by the admin if they are writable to anyone else than root). If there WAS such a directoy in /Applications on my system, though, you could of course just copy the bash or zsh executable there and chmod +s it, and THAT would work. ;-)

The best way to stay secure on your machine is to not change Apple's settings if you don't understand them, and don't run software that you don't trust. If you don't stick to these rules, then it's not going to matter whether you are a normal user or an admin user. If you DO stick to these rules, then it still doesn't matter.

I agree on that. The user himself is by far a greater security risk than working as admin is. But there is even more risk added by the latter, and above all this is a risk that cannot be controlled by the user. So I still urge everyone not to use an admin account for daily work. ;-)

Best regards,

Christian

P.S.: You're right, this is quite OT here, but in my eyes it's an important topic that many people just don't know enough about. Maybe we can make some users present a lesser security risk to their systems this way. ;-)