I read the Wikipedia article on Unix security and the first sentence under "services" used to say that unused software should be deleted. I could not think of a reason, can you help me?

  • 4
    As the article warns in the beginning, additional sources for verification are necessary. I don't really think it's a great investment of your time when you're trying to defend the claim someone else made but did not back up. That extends to us, as well – especially since you don't describe what your inner thought process on this is already (there are a few obvious things that I'm sure you could describe and narrow this down to a precise question that's not actually just an opinionated essay homework question). As the question is currently stated, it's based on an opinion, and far too broad. Apr 13 at 10:18
  • Sadly, both are valid close reasons; so please try to narrow things down a bit, and help us help you by describing what your own thoughts and understanding of the topic are; right now we'd have to write a bit of a longer book starting at "what is a computer and what is software that runs on it, and what do we consider security problems", which in itself is a huge work of opinion. Apr 13 at 10:20
  • An important distinction is the difference between a computer, used as a server and exposed to the internet, and a desktop system which is not acting as a sever of some kind. What are we dealing with? Apr 13 at 11:57
  • 1
    @metablaster that interpretation would be valid, but would not arise from the text he cites Apr 13 at 15:07
  • 3
    @marcelm Marcus Müller removed the content referred to here from the Wikipedia page. Apr 14 at 11:30

4 Answers 4


Any piece of software can contain vulnerabilities or potentially be useful in an attack. Therefore any piece of software is a balance between its usefulness and the risk it brings (the attack surface). If software isn’t used, then it is only a risk (even if that risk is small).

In the context of services, there are additional considerations. Services generally expose something, e.g. a network port; if that is externally-accessible, it can constitute a way into the system. On top of that, services often run with specific privileges (even if not as root), so they can give access to files which regular users may not have access to, and thus be useful in a multi-stage attack.

An additional consideration is that unused software is less likely to be maintained. This is less of a concern if it’s a distribution package receiving security updates. A locally-installed piece of software may however be forgotten about. This also applies to configuration: even distro-maintained packages can be configured insecurely, and if they are unused that is more likely to go unnoticed.

  • 1
    Upvoted, but I'd be curious to know how software that is not a listening service to WAN could be a potential security risk? Apr 13 at 12:28
  • 29
    Even if the service isn’t configured to listen outside the system, it might be possible to use it in a more complex attack, for example privilege escalation after an initial access through another system. Apr 13 at 12:48
  • 1
    This is an excellent answer. I've had to explain this to others many times. Now I'm simply pointing them to your concise answer. Thank you Stephen! Apr 13 at 19:05
  • 2
    @metablaster A relatively easy to understand example would be CWE-426, which potentially allows arbitrary code execution within the security context of the software. If the software component with that weakness is SUID, it turns into a trivial privilege escalation method. Apr 13 at 19:16
  • 6
    To emphasise what Stephen and Austin have said -- vulnerabilities can be combined to be more serious than might be expected from their individual severity. A local privilege execution bug in an unused piece of software might seem harmless... until you find a remote execution flaw (or multiple vulnerabilities that amount to one) in a network service. If the unused software wasn't present, the dangerous combination wouldn't be possible. Apr 14 at 21:04

A software termed services are those software which is opening up a port on local system with the purpose to listen for incoming connections either from LAN (local network) or WAN (internet)

An example of such software is a web server, mail server or any other which serves for users to connect to your system which then provides specific "services"

From a regular user standpoint such as yourself, you might run torrent client such as qbittorrent, this is also an example of such software because it opens up a port locally and let's other peers from the internet connect to your system to share files.

Security risk is that such software might contain vulnerabilities which a potential attacker might exploit in order to gain access to your system beyond what the software is used to.

First step an attacker will do is use tools such as nmap to scan for open ports on your system and use methods with same tool to learn software version and OS being used.
The attacker will then inspect the software source code to learn if there are vulnerabilities and if so he could write code to exploit it.

Of course port scanning isn't directly against a system but against your NAT router which must open up a port for the listening software to be accessible.

That's why updating such software is mandatory to reduce attack surface and reduce vulnerabilities.

Now if there is no need for such software (ex. it's not used) then it's best to uninstall it because this way there won't be vulnerabilities and then there is nothing for a potential attacker to exploit.

But there will be services (software) that is needed and in this case in addition to making sure software is updated you also want to configure your firewall to detect and prevent port scanning.

If you want to see if there is any such software on your system that opens up a port run this command:

sudo ss -tunlp

Link below is my answer that shows a sample firewall setup with nftables to detect and stop TCP port scanning: https://unix.stackexchange.com/a/774404/599939


Consider security principles. Quoting from Computer Security: Art and Science by Matt Bishop (bolding mine):

The principle of least privilege states that a subject should be given only those privileges that it needs in order to complete its task.

If a subject does not need an access right, the subject should not have that right.

According to this principle, any software not needed by a legitimate user for a permitted task should not be available to that user. This includes the root user. By definition, such software can only be used to perform non-permitted tasks, hence it shouldn't be there.

The principle of economy of mechanism states that security mechanisms should be as simple as possible.

If a design and implementation are simple, fewer possibilities exist for errors. The checking and testing process is less complex, because fewer components and cases need to be tested. Complex mechanisms often make assumptions about the system and environment in which they run. If these assumptions are incorrect, security problems may result.

All of this applies to the quantity of software installed on a machine. Less software means less opportunity for vulnerabilities to exist in that software or for mistakes in configuring that software; less work and less chance of a mistake when testing the machine's security; and fewer assumptions needing to be relied on for the machine to be secure.

Put another way, removing unused software is a way to reduce your attack surface. Even if the unused software could only be accessed by a privileged user, removing it contributes to defence in depth.


Another way that the attack surface can be breached is when the functionality intended to autodelete obsolete, temporarily-modified, or discarded code revisions doesn't do its job.

In my case, a database was corrupted when a temporarily-modified version of code that ported numbers to the database got loaded in error and run as the default for several days. Luckily, this did not result in an attack but it did righteously piss off several dozen engineers who relied on those numbers.

The fix in this case was to prevent temporary code revisions from being able to overwrite the original.

  • Nice example! Real experience is better than "Something might..." Apr 17 at 18:06

Not the answer you're looking for? Browse other questions tagged .