The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniWeb > OmniWeb Feature Requests
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Make upgrade function ask for amdin priviledges if not present Thread Tools Search this Thread Display Modes
Well, unless you add yourself to the sudoers file, then you do indeed need to switch accounts. Try editing your /etc/hosts as a non admin user, or build your apache install etc. Try running fink. In fact for that matter, isn't this thread about not being prompted for authentication details when trying to install OmniWeb, and hence not being able to install to /Applications as a Standard User?

That aside, what do you gain by not running as an Administrator? How is your system more secure? What can an admin do that a limited / normal user cannot? As far as I know, write to /Applications and /Library. Malware doesn't need to write to those directories to do any damage. /Applications is not a "special" directory, it's just a convenient place to store your applications. /Library is pretty much just like ~/Library except it applies to all users. OK, there are some folders in /Library where malware might like to hide, such as StartupItems, but guess what! Admins can't do anything to that folder either without authenticating.

I'm only bothering with responding to this cos you said "Running as an admin account on any OS is about the dumbest thing anyone can do, especially in OS X". That's just wrong and when it's in response to me saying that I run as an admin user, you are effectively calling me dumb. If the Omni guys have an installer that doesn't work if you aren't an admin, what does that tell you about how they run their systems? You are welcome to run as a standard user if you want, but don't kid yourself that your computer is more secure because of it.
 
Quote:
Originally Posted by dangerous View Post
Well, unless you add yourself to the sudoers file, then you do indeed need to switch accounts. Try editing your /etc/hosts as a non admin user, or build your apache install etc. Try running fink. In fact for that matter, isn't this thread about not being prompted for authentication details when trying to install OmniWeb, and hence not being able to install to /Applications as a Standard User?
Use your admin username/password as a sudo account in Terminal for the first two. If OmniWeb wants to be able install or update itself in my /Applications folder, I want it to ask for authentication. The point of this thread is that this just fails completely at the moment, not that it is able to update without authentication. If I have OmniWeb in my /Applications folder and I run the update I want to be able to a) have it ask me to install there and b) prompt me to input username and password to do so.
Quote:
That aside, what do you gain by not running as an Administrator? How is your system more secure? What can an admin do that a limited / normal user cannot? As far as I know, write to /Applications and /Library. Malware doesn't need to write to those directories to do any damage. /Applications is not a "special" directory, it's just a convenient place to store your applications. /Library is pretty much just like ~/Library except it applies to all users. OK, there are some folders in /Library where malware might like to hide, such as StartupItems, but guess what! Admins can't do anything to that folder either without authenticating.
What do I gain? It is one more level of security that doesn't exist for an Admin user. Malware can't modify system preferences without my permission, it can't write to folders that affect other users without my permission, it can't compromise my entire system without permission. It can't use exploits such as MOAB #15 to compromise my entire system without my permission.
Quote:
I'm only bothering with responding to this cos you said "Running as an admin account on any OS is about the dumbest thing anyone can do, especially in OS X". That's just wrong and when it's in response to me saying that I run as an admin user, you are effectively calling me dumb. If the Omni guys have an installer that doesn't work if you aren't an admin, what does that tell you about how they run their systems? You are welcome to run as a standard user if you want, but don't kid yourself that your computer is more secure because of it.
My system is more secure because of it. Plain and simple. 40+ years of the UNIX security model tells you that my system is more secure. 20+ years of Windows tells you that running as an admin is not as secure as running as a standard user.
 
Yes, thanks for explaining it so clearly, Jonathan. :-)

Some more points: Yes, you CAN wipe out your whole system as an admin user, as far as OS X is concerned, not the unix core. No problem to completely delete /Applications and /Library—you won't have much fun with your OS after that. True, you can't delete the unix dirs like /usr, but that's not really a major feature.

I'm not exactly sure if Mail.app can be scripted to send a mail without user interaction—I think it is only possible to open a prefilled window with a mail ready to be sent by the user. If so, malicious code cannot send mail if the user's SMTP server requires authentication: The user and pw for the smtp server are stored in the Keychain, and if any new app wants to access those values, the user is asked first to give permission. So if Mail.app cannot be altered, mailcious code isn't able to send mail. (Given that the unix mail engine isn't configured to be able to send mails, as is the default.)

For editing /etc/hosts and similar stuff, just use the unix set user command su. My admin account has the username rozottel; in the terminal I can just type "su rozottel" and then "sudo vi /etc/hosts", e.g.. (Change to a directory your admin account has read permissions for before or after you execute the su command; you will get strange error messages otherwise.)

Unfortunately, I just found out that, by default, it doesn't actually add security to be a normal user giving admin credentials when installing soft to /Applications—the *.app dirs are owned by my normal account, thus giving any malicious code the possibility to write to the subdirs. X-( This is not the case for most software that has been installed by installers (so my complete /Library is safe, e.g.), not by just drag&dropping, but everything else is vulnerable.

If you want to make sure your /Applications directory is safe, do the following:

Open Terminal.app, su to your admin user and cd to /Applications. Then type

sudo chown -R root:admin *

I'd probably better make this a cronjob. :-/
 
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.

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.

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!

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.
 
Quote:
Originally Posted by dangerous View Post
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.

Quote:
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 ...)

Quote:
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. ;-)

Quote:
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. ;-)

Last edited by zottel; 2007-09-10 at 02:20 PM..
 
OK I'm going to continue to agreeing to disagree, and I'm going to continue to run as admin. The only thing I really care about on my machine is the home directory. Having world writeable folders in my Applications directory is not intentional, but that's the way the installers installed them and I haven't bothered to change them. I don't really see a huge problem with it. Bear in mind that I am the only user on my machine, so if anyone else was on it and finding those directories, then I'm already screwed. I'm going to concede defeat here for the sake of not having to reply again because I can't really say that running as admin is more secure, but I think that the difference in security is negligible in the long run, especially if the user knows and can be cajoled into handing over the admin user. I will not concede that running as admin is "the dumbest thing you can possibly do". It's a choice of convenience over a negligible security risk for something I don't really care about, and I think that were you to do a survey of respected Apple users (the Omni guys, Apple developers, whoever), you would find that most of them run as admin users. Of course that's pure speculation, but I believe it to be true.

Over and out, I can only repeat myself from here :)
 
I got a reply from OG people about my request for the updater to get admin privileges. I agree that using the computer as admin is not as dangerous as people might think, but I still prefer using my computer as a normal user. It's a nice way of doing things for somebody like me, who is comfortable enough with Unix to run commands and compile fink packages, but not quite knowledgeable enough to follow this thread fully.

It's a legitimate feature request, whether people prefer to run as admin or as user. :)

Last edited by philonous; 2007-09-13 at 05:22 PM..
 
@dangerous: Yes, that's the point: It's a choice of convenience or security. And yes, you are right, at this point, where there are no known viruses out there in the wild for OS X, the risk is perfectly negligible. But it WILL change in the future, at least if Apple keeps pacing at the speed it does now.

If you choose convenience, knowing the risk and saying for yourself: Yes, I will take that risk, because I like it to be convenient—good. This is perfectly ok with me.

The problem is that many people think there is no risk at all if they work as admin, which is simply not true. THAT's what I don't like and try to change.

Best regards,

Christian

Last edited by zottel; 2007-09-13 at 02:17 PM..
 
Quote:
Originally Posted by zottel View Post
The problem is that many people think there is no risk at all if they work as admin, which is simply not true. THAT's what I don't like and try to change.
Actually that's it. I'm protecting my computer from myself. It's wrong to think that the only risk is external. Do you think I want my parents to run their Mac mini as admin. Hell no!!!
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
About the forecast function oruggt OmniFocus for iPhone 2 2013-02-16 03:32 PM
Ical event sync with automated alarm function or an internal alarm function. narvik04 Applying OmniFocus 23 2011-11-18 01:50 AM
though link-to-tab works, error still present earthsaver OmniWeb Bug Reports 7 2006-06-14 05:36 PM


All times are GMT -8. The time now is 02:59 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.