Tag Info

Hot answers tagged

40

There are two main reasons why smartphones have fine-grained permissions while desktop computers don't. History. Mainframe operating systems have a tradition of giving permissions to the user rather than to the program, and this carried over into minicomputers/workstations/desktops; the desire to maintain compatibility with existing programs limits the ...


18

For technical reasons it is not possible to tell which permissions an application needs until it tries to use them, which means that an application needs some way to declare this. Applications on desktop operating systems never did this. When the user starts a legacy application, you could only assume that it needs everything (training the user to accepting ...


10

It seems to me you're discussing two things: sandboxing on the desktop and then strategies for user content access in sandboxed applications. Sandboxing There are many sandboxing models out there, including the ones used by OSes: Windows 8 WinRT Store Apps OS X Sandboxed Store Apps iOS Apps Android Apps Some apps are shipped sandboxed, for instance ...


8

There are at least two significant reasons why mobile operating systems have fine-grained permissions for apps, while desktop operating systems don't: History. Desktop operating systems date back several decades, when the primary threat model was different, and consequently have mechanisms designed to deal with that (now-largely-obsolete) threat model. ...


5

As a comparison point, take a look at firewall options on a smartphone vs a desktop OS - I think you will find that the desktop has much more fine-grained firewall options (excluding root firewall apps on android), allowing you to specify which executable has access to communications on which ports and on what networks, whereas it's nearly impossible to ...


3

Giving the desktop client the keys to the kingdom is by definition a violation of CWE-602: Client-side enforcement of server-side security. Any piece of software running on an attacker's machine cannot be trusted. There needs to be an intermediary API, a web service that you control, and provides the ability to enforce user-based access control to a ...


1

It's actually only Windows that doesn't have that. (Except appstore apps). On OS X you have to give permission before things like contacts can be accessed or if an application wants to do filesystem changes to anything outside the user's container. For Linux there are things like AppArmor an SELinux, but on most unices, bsd's an linuxes the normal ...


1

I think it comes down to what you consider to be a "same origin" for a desktop application. In a perfect world ignoring some Windows functionality: Is it a process? Process A can't access Process B memory. Is it a user? User A can't access User B's files. Is it user session? If you're not in Session 0, then you're not SYSTEM. So I think sandboxing a ...


1

secure desktop runs under local system account and no other process can interact with it except OSK,Narrator etc,it is started by winlogon.exe and you can disable it in registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System by changing the value of PromptOnSecureDesktop from 1 to 0 if you run cmd.exe under system account it ...


1

There is no isolation between GUI apps on X11, so that allows your user to spy on your clipboard's content, create windows that may look like spoofs of your own windows (e.g. spoofs of your polkit1 dialog or screen locker), record your entire monitor, implement a keylogger... Just create a guest session, seriously. Or use a VM. I would not trust other ...


1

In your case, there really is no avoiding policing the API use yourself. Since the API is assigned to (you) the developer you will need to host some sort of server to provide access control to dropboxes API. Read Drop Boxe's terms of service carefully.


1

The scenario you describe qualifies as a cross-platform attack simply by the fact that one device attacks another. The mobile app containing worms may not harm the mobile device itself, but it is by any other name a malicious, infected device. When plugged into the PC, it launches the attack to that platform, thus making it a cross-platform attack. A ...


1

As an immediate patch, you should run such an application in a separate X server on a different VT. This is the only way you can guarantee that the app does not use the X API to spy on other clients. You may also try your hand at XSELinux but I know of very few people in the world who know how to run it, and it usually severely limits what your target app ...


1

Sprinkling crypto fairy dust will not prevent the attacker who controls the client from making the client do anything s/he wants with it. S/he can still redirect it to localhost, but now needs to replace the public key you embedded with the app with his/her own public key. Or attach a debugger and disable the use of crypto entirely. Or decompile, remove use ...


1

To get to another aspect of the question: Same-Origin-Policy is an important security boundary and it sounds nice in theory. But, like with other security boundaries, it is often in the way so it gets frequently worked around in praxis. The most common workaround is to include third-party sides as script. Advertisements, tracking or social networks are ...



Only top voted, non community-wiki answers of a minimum length are eligible