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 473760
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Can't get excited
by WereCatf on Thu 19th May 2011 16:43 UTC 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