Well, there are two separate aspects in running an application as root; one of them improves security and another one may compromise it - I think mixing those two aspects explains your confusion.
running an application as another user (possibly root user, but not necessary) makes it more difficult for another process to access files owned/created by that application and do other nasty things (send a KILL signal, for example). This is good.
if an application happen to have a vulnerability (i.e. sending it some specially formatted input makes it to execute some code via buffer overflow etc.) - then, after exploiting the vulnerability, the attacker will be able to execute code with the privileges of that process. In this sense, running an application with root privileges is BAD, because it would give the highest level of privileges to attacker.
Now you understand that running update manager as root may be bad if it contained a bug which would allow a specially-crafted .deb file to crash it and make it to execute some code. However, running some applications, such as package manager, with superuser privileges is unavoidable because they modify the essential parts of the system.
The common solution to this problem is to perform so-called "privileges drop" on program startup; this is often used to run webservers and other potentially exploitable (and accessible from outside) software. The idea is simple: the program starts as root, but as soon as possible it switches to some user account with as little privileges as possible (no shell login, chroot-ed to its home directory etc.) This way, even if compromised, it would give attacker a very limited access to the system. Also, other user accounts (except the superuser) will have no access to the application's files
I'm not sure how easy would it be to run a desktop application like this though.
Actually, in this situation I think running web browser as a non-privileged user would make more sense. And, of course, Google gives us a few links on the subject:
Taking this idea to the extreme (as you're suggesing in the comments) will give you a system which is similar to how Android works; on Android each application operates within its own user account, so it only have access to its own files. This probably have some problematic areas in Ubuntu, i.e. if you downloaded a file using Firefox running in a restricted account, it'll only be able to save it in its own home folder so it won't be possible to open the file in a text processor (which runs as another user)...
Regarding the launcher script I would imagine the script will be starting as root and invoking the applications as their respective users. The script will obviously need to be writeable by root only. Read about setuid.
Best Answer
You can use the open-source Pluggable Authentication Module (PAM) created by Google, known as the Google Authenticator. This module is available in the standard repositories, as well as from GitHub so that you can build from source. Coupled with the Android, iOS, or Blackberry App of the same name, it creates time-based, time-sensitive codes for authentication along with your password. Since it is a PAM module, it can be dropped in pretty much anywhere. Let's get started!
Installing
To start, you can install the PAM with the following:
Simple!
Setting it up:
After it's installed, you will want to also install the corresponding mobile application for Android, iOS, or Blackberry (depending on your mobile platform). Each one is useless without the other. After you have the application you need for your mobile device, run the following in a terminal:
This will start by asking you a few questions The first one is the only one which you must answer "Yes" to, and it asks if you want the codes to be time-based. After that, read each question and make the choice that makes the most sense to you.
Upon completing the initial set-up, you will see a very large QR code in your terminal, as well as some other information. The line that says "Your New Secret Key Is:" is a much needed line if you don't want to use the QR code for pairing your device, so don't close this window until you are set-up! The "scratch codes" this gives you are also important, as they are what you will use to log-in if you lose your mobile device. Write them down and store them somewhere safe.
Now, on your mobile device, open your Google Authenticator application and select "Set up account". You can either scan the QR code that was generated, or select "Use provided key". If you scan the QR code, everything will be automatically saved under an account named "your_user@your_host". However, if you select "Use provided key", you will have to enter a name, key, and type of token manually. The name can be anything you wish. The key would be the secret key previously generated. The type would be the default time-based. After setting it up, you will see the account on the main pane of the Google Authenticator app, as well as a circle-shaped timer next to it. That timer depletes every 30 seconds, and a new code is generated.
Enabling it!
Here comes the magic. Since this is a PAM module, it can be used in a variety of places. I will walk through adding authentication to
sudorequests, SSH log-ins, and lightdm log-in. However, after reading this tutorial, you will be able to enable it elsewhere based on the same techniques.SSH
I'm doing this one first because there is an extra step. The first thing you need to do is to edit your SSH config file:
Search for the line that says:
and change the "no" to a "yes".
Now, you need to edit the PAM module for ssh:
At the very end of this file, add the following line:
The "nullok" argument tells the system to not request a verification code if a user has not set-up two factor authentication. After that edit, go ahead and restart your ssh service:
sudoRequestsEdit the PAM file for
sudo:Add the following line at the very end:
Now every
sudorequest will ask for a verification code as well as a password.LightDM (GUI Log-In)
Edit the PAM file for LightDM:
Add the following line at the very end:
That's it! Everytime you log-in through the GUI, it will ask for a verification code after your password.
System-Wide and TTY Log-In
Even if you enable the above methods, it still won't ask for a verification code if you switch over to a TTY with CTRL+ALT+F#. To fix this, edit the
common-authPAM file:and add the following line to the very end:
Note: Since this common-auth file is included in all other auth type files, you need to remove the auth required lines from the other files. Otherwise, it will ask for the verification code twice and not allow you to log-in after.
Wrap-Up
As you could see, it was pretty easy to add this authentication in. If you use a display manager other than LightDM, you could easily just change the lightdm line above accordingly. Since your mobile device and your system shared this secret key already, they should always be in-sync. There is no interaction with Google servers, or any other internet resource for this set-up. Even if both devices were completely offline, the verification codes that show up in your application will be correct. Whenever you need to log-in through one of the methods you've enabled, just make sure to open up your mobile application and grab the current verification code.
Have fun!!