Linked by HAL2001 on Thu 19th May 2011 12:10 UTC
Privacy, Security, Encryption "A little over two weeks have passed since the appearance of MAC Defender, the fake AV solution targeting Mac users. And seeing that the approach had considerable success, it can hardly come as a surprise that attackers chose to replicate it. This time, the name of the rogue AV is Mac Protector, and the downloaded Trojan contains two additional packages. As with MAC Defender, the application requires root privileges to get installed, so the user is asked to enter the password."
Thread beginning with comment 473745
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Can't get excited
by WereCatf on Thu 19th May 2011 14:56 UTC in reply to "RE: Can't get excited"
WereCatf
Member since:
2006-02-15

At the risk of getting annoying with my sandbox advocacy... How exactly are you supposed to know *why* some piece of software requires admin rights before installing and running it, on nowadays' desktop OSs ?


On current OSes it's not easy, I admit that, but if someone wrote a completely new OS they could separate every API in use to two categories: privileged and non-privileged. Even file system access would have to be separated for it to be effective, and so if your application used e.g. PrivFileOpen("somefile.txt") instead of FileOpen("somefile.txt") the system would immediately notify about it and halt execution.

Similarly, executables would have to list in the executable file every function call they use (excluding parameters though) so that if the application tries to use a function call not specified it would again get halted.

Then at installation time OS would present the user with what permissions the application is asking for, ie. what privileged functionality or data it wants access to, and a short explanation of what each item might entail and possibly a warning based on heuristics on the permissions being asked.

Sure, it would require helluva lot of work and careful design from the OS developer(s), but it should still help atleast a little. Of course there are still those luddites who just click away, but clear-text explanations for items should again help with atleast some of them; people often just click "Ok" or "next" because they don't understand what's presented to them, not because they don't care.

Reply Parent Score: 1

RE[3]: Can't get excited
by Neolander on Thu 19th May 2011 15:12 in reply to "RE[2]: Can't get excited"
Neolander Member since:
2010-03-08

Happy to see that I'm not alone wanting OSs to work that way ;)

Though I would rather not incorporate the privileged/nonprivileged status of API calls at the function name level on my side. There would just be a set of default privileges, like "Accessing ~/.%APPNAME%" on an unice, that would be granted to everyone and would be well-documented in the API doc.

This would in turn allow new backwards-incompatible releases to change the set of default privileges, if experience shows that there was a mistake in it somewhere.

Edited 2011-05-19 15:14 UTC

Reply Parent Score: 1

RE[4]: Can't get excited
by WereCatf on Thu 19th May 2011 16:43 in reply to "RE[3]: Can't get excited"
WereCatf Member since:
2006-02-15

Happy to see that I'm not alone wanting OSs to work that way ;)


I've been thinking for years of how I would write my own OS if I ever did one, and strong security from bottom up is one of those features I'd like to implement ;) I've got lots of ideas, both security-related and non-security-related, but even writing down all the aforementioned ones would be way too much to fit inside an OSNews comment form :/

Though I would rather not incorporate the privileged/nonprivileged status of API calls at the function name level on my side. There would just be a set of default privileges, like "Accessing ~/.%APPNAME%" on an unice, that would be granted to everyone and would be well-documented in the API doc.


The reason why I'd separate them is exactly because of this thing you mentioned: non-privileged calls would only have access to your files, ie. ~./*, and trying to open anything outside of your files would immediately generate a warning and you'd need to use privileged calls for that. It would allow for slightly more fine-grained control, plus it would allow for more fine-grained status messages, both to the system and to user. And it would force developers to pay a little bit more attention to what they're doing themselves, which is only a good thing; just get a handful of Windows apps and there's bound to be some examples of what I mean.

Edited 2011-05-19 17:01 UTC

Reply Parent Score: 2

RE[4]: Can't get excited
by moondevil on Fri 20th May 2011 14:45 in reply to "RE[3]: Can't get excited"
moondevil Member since:
2005-07-08

This is a bit like Symbian works.

Your application needs to have specific certificates depending on which APIs it calls.

Reply Parent Score: 2