Linux – How to completely remove the user subsystem from Linux

There are countless reasons one might try to compromise a system's security. In broad strokes:

• To use the system's resources (e.g. send spam, relay traffic)
• To acquire information on the system (e.g. get customer data from an ecommerce site).
• To change information on the system (e.g. deface a web site, plant false information, remove information)

Only sometimes do these things require root access. For example, entering a malformed search query on a site that doesn't properly sanitize user input can reveal information from the site's database, such as user names / passwords, email addresses, etc.

Many computer criminals are just "script kiddies"; i.e. people who don't actually understand systems security, and may not even code, but run exploits written by others. These are usually pretty easily defended against because they don't have the ability to adapt; they are limited to exploiting known vulnerabilities. (Though they may leverage botnets -- large groups of compromised computers -- which can mean a danger of DDoS attacks.)

For the skilled attacker, the process goes something like this:

1. Figure out what the goal is, and what the goal is worth. Security -- maintaining it or compromising it -- is a risk/reward calculation. The riskier and more costly something will be, the more inticing the reward must be to make an attack worthwhile.

2. Consider all the moving parts that effect whatever the goal is -- for example, if you want to send spam, you could attack the mail server, but it may make more sense to go after a different network-facing service, as all you really need is use of the target's net connection. If you want user data, you'd start looking at the database server, the webapp and web server that have the ability to access it, the system that backs it up, etc.

   Never discount the human factor. Securing a computer system is far easier than securing human behavior. Getting someone to reveal information they shouldn't, or run code they shouldn't, is both easy and effective. In college, I won a bet with a friend that involved breaking into his uber-secure corporate network by donning a revealing outfit and running into a lecherous Vice President -- my friend's technical expertise far outweighed mine, but nothing trumps the power of a 17yo co-ed in a short skirt!

   If you lack boobs, consider offering up a pointless game or something that idiots will download for fun without considering what it really might be doing.

3. Look at each part you've identified, and consider what it can do, and how that could be tweaked to do what you want -- maybe the help desk resets passwords for users frequently without properly identifying the caller, and calling them sounding confused will get you someone else's password. Maybe the webapp isn't checking what is put in the search box to make sure it isn't code before sticking it in a function it runs. Security compromises usually start with something purposely exposed that can be made to behave in a way it shouldn't.

You will be probably best off with either a security framework implementing RBAC or MAC (grsecurity for the former, SELinux, AppArmor, Tomoyo Linux for the latter) which lets you define finer grained permissions per application.

Apart from that, recent Linux kernels offer namespaces which allow you to change the way different processes see the whole system. If you mount empty directory over say $HOME for the untrusted process, it won't be able to read your files.