Your Distro is Insecure: Ubuntu

Ubuntu Server has one of the cleanest and easiest Linux distribution installers. However, in many cases, its designers choose to ignore security in favor of ease-of-use. The result? An install that is not secure by default.

During the last couple of years, Linux distributions have focused on improving the installation process of Linux in order to make the freely available operating system available to more people. It’s a noble goal, however, when making anything in computing easier, a common approach is to make a number of decisions for the user — decisions that can put an inexperienced (and possibly an experienced) Linux installer at risk.

Unfortunately, many Linux distributions make a number of painfully wrong security decisions at install. All too often these issues are overlooked by the administrator since the prevailing wisdom tends to be: “If it’s Linux, it’s secure.” As we’ll soon see, that’s not always the case.

For this article we’ll look at Ubuntu Sever version 8.10. The methodology used to determine if the installation is as secure as it could be is three fold:

  • Identity,
  • Authentication, and
  • Authorization

Identity is key to providing access to computing resources. For most internal services, identity of confidential information must be limited to those needing the information. Typically this is based upon user identification. To determine the identity of the user it must be validated via authentication (passwords).

Authentication is key to ensuring a system is secure — since any security gained by identifying a user is quickly lost if weak authentication is used. Weak authentication can be caused by users (for example sharing or losing passwords), but weakness from a system standpoint will be reviewed in this article.

Finally, authorization is necessary to ensure the appropriate resource are authorized for the user. This allows individual resources on a server to be further managed; for example, directories, printers, etc.

Excuses, Excuses

It is common for Linux proponents (and the makers of operating systems on their chosen platform) to rationalize away many of the decisions that go into developing an installer. The most often cited reason for a lack of security is based on the idea that security does not go hand-in-hand with ease of use. This article will show how and when wrong security decisions are made by installation programs and a more viable and secure secure resolutions you can use to counter the issues.

Another common reason given for a lack of security is that a distribution is actually a collection of software and that the individual packages should be secure by the maintainer not the distributor.

This justification of bad behavior by more bad behavior is simply poor practice — if the distribution is making decisions on behalf of the user, then it should make a solid decision and not push decisions within its control back on the package maintainer. (In fact, the distribution should help assist the community and point out to the package maintainer, any security concerns it or its users have identified.)

Security During Installation

Let’s begin with a fresh install of Ubuntu Sever 8.10.

One of the immediate security concerns that come to mind during the installation of Ubuntu, is making the user’s home directory world readable: “The contents of your home directory will normally be visible to all users on the system” as shown in Figure 1, “Set up users and passwords”.

Figure 1: Set up users and passwords
Figure 1: Set up users and passwords

Permissions open by default? In a rather odd twist, since the directory is wide open, the installer attempt to plug the hole by providing the option to encrypt a private directory!

A closer look at the permissions validates the files are world readable:

drwxr-xr-x 2 rmccarty rmccarty 4096 2009-04-13 09:40 rmccarty

In addition, any additional users will be created by the useradd command world readable due to the entry:


in the /etc/adduser.conf file

Continuing now, during the software selection phase of the installation, the following items were selected for installing: DNS Server, LAMP server, mail server, OpenSSH server, and the Virtual Machine host, as these are most likely the instances the server version of Ubuntu would be deployed in a typical setting.

As the installation chugs along, it asks to change the “root” user password for mysql. This is excellent as mysql installs by default without a password set for the user “root” (root under mysql control, not the root account on the system). Unfortunately, the installer does allow the user to leave it blank rather than forcing the user to enter a password. The installer also does not enforce any minimum password lengths or rules. Another instance of choice trumping security.

For these gotcha’s Ubuntu gets an A- on the report card for authorization whenever it could easily have gotten an A. Making users files world readable to ease installation but then pushing the issue back on the administrator or user to address is not ease of use.

Next: Securing Your Network After Install

Comments on "Your Distro is Insecure: Ubuntu"


This is good in that I’ve noticed many of these in servers I use in the past and thought they were superfluous, but Linux admin is not something I do other than when I get forced into it–just not my real job. However, I’m not sure from the article’s close that this was a complete list or simply where the author ended. That would be good to know. I’m also in a bit of mystery about some of those extra users–when and under what circumstance are they needed? It also might have been helpful to illustrate a sample of the fixes to remove any lingering questions–I realize that is probably very basic for most readers, but it is critical for the reader missing that last bit of “how to” knowlege.


I took the time to read this article because I was worried about my computer. Instead, I find a bunch of anal retentive drivel that would seriously inconvenience many desktop users. Admittedly, the article talks about Ubuntu server, and may have valid points for people installing a server. Perhaps, it should have been titled “Your Linux Server Installs Insecurely” so that it would only reach the audience interested in it.


I doubt this article was meant for typical standalone workstations.

I agree there is a concern with the open user directories, but outside educational installations, true multi-user machines are becoming rare. For instance, with my provider, I am the sole user of a virtual machine. Isn’t that the rule nowadays?


This article probably shouldn’t have singled out Ubuntu. Although the brief information presented is true, it is also true of other Linux Distros and other varients of UNIX. The “Open by default” approach is often taken. I’ve worked on Solaris, HP-UX, Linux, etc for many years and if you want to secure them you have to clean it up after it’s installed. (Unless you get a pre-secured version…) This is only a couple of specific open issues – there are many many more areas. If you want to secure a system you have to start by ONLY installing and running the services you really need. Then remove/close off accounts, ports, SUID programs, etc. You will never secure a system when you just load and go.


OMG. This article is crap. FYI, Ubuntu uses dovecot for imap/pop. Dovecot supports only POP3 and IMAP4rev1. netstat can’t tell you what version of protocol is in use (telnet to the port and check it for your self!). bootpc/UDP – your system is runing dhclient (I guess you haven’t configured network in /etc/network/interfaces). bootps/UDP – you are even funnier; you are running DHCP server on you machine. Mind you, Ubuntu server won’t install dhcp server by default – it doesn’t even have a task for dhcp server. Are you trying to spread FUD?

‘So when any of these accounts are compromised interactive remote access is most likely the results.’

LOL! /bin/false would prevent that? How? What would stop attacker of running chsh?

You are totally clueless.


actaea- I agree with you 100%. In fact I was looking for something mature,instead what we get is rather disingenious in the least. This is supposed to be a server. To share files and serve sevices to users. This would normally be installed by an Administrator, unless it is for home use. Since it allows you to chose you password or leave it blank, that is your choice. And I agree. Because in a test environment, where the system does not have internet access, that can work wonders easily. I happen to have set up some servers on a test network and I know that in a real network I use secure pass phrase wherever possible. But I DO NOT want the hassel of entering a password everytime. Because I have no need for security at that level. And the services that are installed by default more than likely are a result of user response to beta testing etc. For your security purposes you would hae turned off these services. But for the general use, they may be required by others. These are suposed to be multi use systems and are a cheaper alternative to vmware. On the upside you can create a secure distro and post it. And it seems with most systems, that you will definitely need to make them secure before deploying them. Right?


I basically agree that all of these points have some validity.

But most of this are really _very_ shallow/ambiguous problems. I.E:
* is Non-TLS:ed pop3 really allowed? As matador mentioned, you can’t know that it allows plaintext, just because it’s port 110. Modern TLS handshakes often run on the same port as the older versions.
* While the shared-home-dir would be a problem on a company server, I would probably consider it a feature on a family-desktop or a home-server. Ubuntu is a Desktop for many uses you know. However, I agree that it should be an informed choice during installation. Cookie-stealing and whatnot. And who have never accidentally managed to write some sensitive info to the wrong files? An Inotify on the relvant files of your friends, and you could propably harvest for some mischief.
* As matador says. Buffer overflow in any service would not in any way be rescued by whatever etc/passwd says. The only added security would be in combination with a bad admin, setting a weak password when password on services that shouldn’t have password. Only in this particular instance would passwd even matter.
* Also, I wonder how you managed to install the dhcpd? If that was unclear during install, that’s a general usability-issue, not only a security-issue (also may cause problems on network, consume needless resources and all kinds of bad). Same mostly goes for dhclient, should not be running if you’ve really configured statically, for many more reasons than just security.

But what about the _really_ interesting stuff? Things I’d REALLY find interesting for security in a server (and I have no idea of Ubuntu Server, never tried it):
* Is stack and heap-randomization enabled in the -server kernel?
* Is iptables configured with careful defaults?
* Is apparmor/selinux configured at all? (Sadly, this is one of the things I’m often forced by time to remove from CentOS-installs just because it breaks some apps and I don’t have the time to dig enough to learn and fix it properly.)
* What binaries are installed setuid?
* Is there any IDS pre-configured?
* Even simple things like denyhosts?

So, all in all, while all your points hold some validity, they wouldn’t exactly turn me away from Ubuntu Server by themselves.


Given the issues, it seems like there’s a bit o’ grade inflation going on. I’d say that B or B- are more appropriate grades.


I am missing the point of this article. Isn’t it a given that a fresh install will have little to no security? Even distros like EnGarde need post-install configuration. If you want a secure system and doesn’t have the know-how find someone else who does. If it’s your job to secure the system you may be better off looking for another line of work.


1) There are numerous protections in kernel and during compilation of programs –
2) There are no iptables rules by default. If you enable ufw, you get some
3) apparmor is configured (mysql, bind9, slapd…)

denyhosts is available in repository, but enabled by default. Same goes to fail2ban (which might be better option than denyhosts)


‘but not enabled by default’


That’s why I use Debian, especially for servers. It’s more stable, and secure.


Bahahahaha! Linux really isn’t for everybody.


Those extra users are merely a placeholder and are disabled by default. It is not possible to log into these accounts without using root.


What about 8.04 LTS


Yeah, what boban said. I’d be more interested in hearing about an LTS version, as those are the only ones I would ever put on a production server.


I have this developed over time I have not updated for 8.0.4 other than DJBDNS everything will work as described


Thanks for every other informative web site. Where else may just I am getting that kind of info written in such an ideal method? I’ve a project that I’m just now working on, and I have been at the glance out for such info.


Hello there! I know this is kinda off topic nevertheless I’d figured I’d ask.

Would you be interested in trading links or maybe guest authoring a blog article or vice-versa?
My site addresses a lot of the same topics
as yours and I feel we could greatly benefit from each other.

If you’re interested feel free to send me an email. I look forward to hearing from you! Wonderful blog by the way!

my blog post develop iphone apps on windows


These De – Puy products were proven to be defective and harmful to the patients
who used them. We are able to bend at the hips and perform other
activities concerning the hip thanks to this bone.
(2) compression of abdominal contents results, impeding circulation,.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>