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 473749
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Can't get excited
by Neolander on Thu 19th May 2011 15:12 UTC 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[5]: Can't get excited
by Neolander on Thu 19th May 2011 19:28 in reply to "RE[4]: Can't get excited"
Neolander Member since:
2010-03-08

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.

Myself, I aim at something a bit more restrictive as a default setting : software only has access to its own files and to files which you explicitly give them access to, either via command line parameters or via "Open/Save file" dialogs in a GUI.

Normal utility software has no business peeking at your files without asking for permission first. User files are his/her private property, at least in my opinion ;)

It would allow for slightly more fine-grained control,

Why does separating privileged and non-privileged code at the API call level allows for more fine-grained control ? Can't the implementation of SomeFunction() itself check if the instruction is privileged or not, and if it is issue a warning or halt the program, all that being done through a standard API for optimal user experience/security/whatever ?

plus it would allow for more fine-grained status messages, both to the system and to user.

Again, to me it sounds like a benefit of a fine-grained privileged model as a whole, not of your solution in particular ;)

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.

What you said ;)

Edited 2011-05-19 19:29 UTC

Reply Parent Score: 1

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

RE[5]: Can't get excited
by Neolander on Fri 20th May 2011 22:38 in reply to "RE[4]: Can't get excited"
Neolander Member since:
2010-03-08

Yeah. I think Android also works this way. For once, mobile OS' low-level layers prove to be better-suited to their job than desktop ones ;)

Edited 2011-05-20 22:54 UTC

Reply Parent Score: 1