I'm remastering an Ubuntu based distro, meant to be used live only and primarily as a browser so a users hard-drive can be virus free while online. This live browsing adds security for Linux users, but seconds as a Guardian for Windows and Mac users hardrive. It is a nice invitation for their users to take a look at what the Linux OS has to offer to help protect their chosen OS's. I'm adding an easy grandma tutorial so they can remaster it with all their browser and user space customizations.

Most users will want a password manager to help them sign into their accounts. I'm using Firefox, but the Firefox password manager once opened with the master password will give any requesting service that knows how to make a request unhindered access to all encrypted passwords. Due to this, I've decided to go with a stand alone password manager which will give some permission flexibilities to help deal with those issues. Keepassx has been the main choice.

There is a similar problem, in that, malicious code could access the Keepassx data base because both malicious code and Keepassx would share the same privileges in the online users space.

In order to add more security, I'm considering changing Keypassx permisions so the Keepassx data base is not accessible to the online user, unless the user enters their admin password. This logically would result in making it harder for an attacker to access. Although, I'm new to setting up security environments. Therefore my question...

Is it a good idea and safe to force Keepassx only to be launched as root user on Ubuntu, taking in mind the user will be online with Firefox?


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.

  • Your info and links gave me some ideas. How does this sound: The live disk will have several accounts: Account Users: browser torrents password administrator Each account will have their privileges set according to what the minimal level to do perform the operations their names suggest. – bambuntu Feb 17 '12 at 7:14
  • You will not have do fast user switching when all the services need to used with this solution: Each app will be wrapped with a python script. The python will to this: 1. su usernameHere 2. execute relevant app 3. sign out – bambuntu Feb 17 '12 at 7:17
  • All the time, administrative user can have all their apps running as different users with appropriate priveledges, yet graphically see them all in one account. You were implying it may be more secure to run the browser as a user without the possibility of having elevated priveledges. Does this satisfy that security situation, yet still allow the users who launching these python wrappers the potential maintain things as root when neccessary. I understand it may not solve all issues, but does it sound like a good first line of defense? – bambuntu Feb 17 '12 at 7:17
  • I meant to say that the python wrapper for launching apps should sign in as the user calling these scripts, admin, not sign out. – bambuntu Feb 17 '12 at 7:25
  • I've updated my answer – Sergey Feb 17 '12 at 7:47

I might be wrong on this but it is my understanding that if you give a utility root privileges and it gets compromised by malicious code, then the malicious code also gets root privileges.

It is my understanding that for this reason Ubuntu handles security differently from other distributions. It does not install a root user. It installs a user that gets root privileges when that user, as administrator, needs root privileges. Once the task is finished or the time limit has been reached the user with administrator access loses the root privileges. This reduces the risk of malicious code getting root access.

This is why in Ubuntu we do not use "su" but "sudo" before a command in the terminal. We limit the opportunity for malicious code to get access and do damage by restricting our use of root privileges.

This is the document that I get my understanding from:

Ubuntu reasons for sudo and not su or root

I strongly advise you to consider the reasons that the Ubuntu developers have for doing things this way. It is those reasons that cause me to say that what you intend to do is not safe.

I quote the official document:

By default, the Root account password is locked in Ubuntu. This means that you cannot login as Root directly or use the su command to become the Root user. However, since the Root account physically exists it is still possible to run programs with root-level privileges. This is where sudo comes in - it allows authorized users (normally "Administrative" users; for further information please refer to AddUsersHowto) to run certain programs as Root without having to know the root password.

  • Technically the root user exists (it's a Linux imperative) and it can be enabled for login, but your understanding is sound. Running things as root is best avoided and that Ubuntu Desktop doesn't give you a root login by default. For that reason. – Oli Feb 17 '12 at 1:53
  • I did not want to complicate the issue with technical matters. My own understanding is limited. It is based on what I have read on the subject. – grahammechanical Feb 17 '12 at 1:59
  • So when something requires root privileges, does that mean we have to type sudo to run it? I mean there are several things running as root when we go online to support the Ubuntu's functionality. Is this a threat, in that the fact they are running because root privileges were required to get them started? – bambuntu Feb 17 '12 at 3:07
  • If a program used scripts on a local drive and malicious code changed those scripts, I could see how a program launched as root would be a problem. This is why I was thinking that storing the app in a root protected area would ward against such an attack. The files it would make would be privileged only to root as well. This protection couldn't exist if the program was ran as regular user. All privileges would be wide open to services or apps with identical privileges. What I see as protection, is being called a security risk. I'm confused. – bambuntu Feb 17 '12 at 3:38
  • I'm sorry but the whole second paragraph is one big misunderstanding of the concept, every single sentence :) The quote you provided explains everything much better – Sergey Feb 17 '12 at 5:00

No, it's not a good idea. It may break, and it may allow escalation to root.

Keeping the password database safe from accidental or malicious exposure by other processes running as the same user is not trivial but it is worth trying. But, that is much better done upstream in the Keypassx project, and by means other than running it as root.

  • I want to make sure we mean the same thing when we say "running as root". If I sign in with sudo su and start a process is that the same as using sudo to run the program? Are both considered running it as root? If so, then is running anything with sudo a threat? Even package manager? Should we not run package manager? – bambuntu Feb 17 '12 at 2:57
  • Yes, in both cases the process has uid=0, ie it is running as root. The package manager has to run as root to chaneg system files; there's nothing wrong with doing that, or with for example running vim as root to change files in /etc. There is a lot wrong with running random programs as root when they are not designed or intended to be used that way and they don't need the escalated privilege. – poolie Feb 17 '12 at 4:29
  • What if the program has no innate coding vulnerabilities. For example, I mean a simple "hello world" script. I'm trying to understand what I need to protect against. Is there something that has to be done extra to protect a "hello world!" script just because it's ran as root? Or is the problem in the programs coding, like say for instance running a script from files that non-priveldged processes can read and write too? In that situation root running process may get tricked into code that is destructive. So, which of the two? – bambuntu Feb 17 '12 at 4:48
  • See Sergey's answer. – poolie Feb 17 '12 at 4:56
  • poolie, thanks for links, see my message above it's also directed to you. – bambuntu Feb 17 '12 at 7:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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