1

I am developing an application which can install extension modules (plugins, if you will) from APT-style repositories hosted elsewhere. The plugins need not be signed (although the downloads are verified), and can be downloaded over basic insecure HTTP. Is it a good idea to require the user's password (in a similar way to sudo) to download packages, or just to install them? Should I require a login at all?

To be more specific: should I verify that the user installing the packages is authorised to do so client-side?

1
  • 2
    This seems like a 'it depends' question. Feb 17, 2015 at 23:06

2 Answers 2

2

While there are multiple approaches here, the best approach and the key to security on the desktop is to assume that any userland software running is already compromised. In other words, place your trust in the operating system, not the programs. If the operating system is compromised... it is time to replace the computer.

You mentioned sudo as a way to authenticate to install (not download) system packages. This is because the package manager is locked down and requires root (group or user) access. In other words, apt-get does not enforce security itself, it simply does things that require root access. On my system it is r-x for the root group, of which I am a user. So I can execute it, but it cannot do anything useful unless it runs as root because the things it attempts to do require root access.

In the same vein, a userland program should not care too much about security. Instead, it should rely on the credentials of the logged-in user to allow it to access system resources that are secured by the operating system. If the user needs elevated privileges, then run as root, use sudo, or right-click and "run as administrator" in Windows.

In theory, any application-level security can be broken in a matter of time by anyone with access to the system.

Even server software such as SQL Server follows this model by preferring to rely on system groups and privileges. If you try to use SQL Server authentication and turn off the group-based security it will warn you this is not secure -- because it is not.

Remember, the OS is in a special, privileged execution environment that gives it unfettered access to all system resources. Applications in modern operating systems do what the operating system allow them to do. Leverage that built-in security and do not reinvent the wheel.

To address your question more directly, it can be acceptable to authenticate in the program itself if you are installing plugins to the user's profile, localizing any damage to the user's account. However, that is rather pointless as you do not require any different privileges to finish the action. I would still recommend not authenticating, and relying on the built-in security to let the action succeed or fail (in this case, most likely succeed).

The only time it truly makes sense to enter a password without elevating privileges is for encrypting or decrypting data: but that should not be a user account password anyway.

0

I think this really depends on the nature of your application. Is it for an individual or something that could be run by many on a server environment? Is it for a technical user or somebody less technical.

Take Eclipse, for example. You can connect to any repo and download plugins without needing to log in. The users that are going to be doing that, though, are technical in nature and are operating (hopefully) on their own machine where not much could get screwed up.

I think you should implement some sort of preventative guard (such as a sign in) in the following cases:

The target user is a non-technical individual and this is an application that could be used in a business

Locking it down would allow the people who know what they are doing to modify and/or install the plugins. It also allows for uniformity in the environment so that if there are any issues the internal IT can make easier work of it.

The application is going to be on a server

If the application is going to be hosted on a server, it is a good idea to password protect it so that not everybody who has access to the server would be able to modify the program at will.


Any other time, I wouldn't think that it is really necessary to put the safe guard in place since it would be a non-secure setting for an individual.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.