Ubuntu – How to disable the Terminal Emulator for certain users

First of all let to point out that privileged actions are allowed for a non-root user through two different mechanisms.

1. sudo

2. PolicyKit

The first one is used when you explicitly run a command with sudo or a menu item whose command is wrapped with gksu (like Synaptic Package Manager).
In this case the password required is that of the invoking user, usually the user logged in.

The second one is used when a PolicyKit-aware application try to perform a privileged action. In such a case the application asks the PolicyKit Local Authority (through D-Bus) if the action can be executed. The Local Authority then, through an Authentication Agent, asks the active user to prove its identity. The dialog windows is like the following (unfortunately with text in italian :)

You can identify PolicyKit from the little black triangle and the label Details. As you can see, if more that one user is in the admin group, you can choose from the list which user to use for authentication.

Given all this, both sudo and PolicyKit are much more complicated, with respect to the configurations that can be achieved: you can configure action that can be executed without password, executed only by a particular user or group, etc.

Coming to your question, when the mechanism used by the application is PolicyKit, independently from the current logged in user, the password required would be that of Bob or Alice (the only two admin user, if I understand correctly), and you can change from the list which user you want to use for authentication.

When the mechanism used by the application is sudo (for admin tasks performed through GUI this is becoming less frequent), you have no immediate and simple mean to choose the user for authentication.

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:

• Running Firefox as another user, using sudo

• How to Set Up and Run Firefox 3.0b2 as a Different User in Ubuntu

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.