Linux – How to replace setuid with file-system capabilities

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.

As mentioned in this Kernel Mailing List message, whether a process needs extra security is checked in cap_bprm_secureexec() of the kernel file security/commoncap.c, which does check for capabilities. This is then exported to the process via the auxiliary vector. This can be accessed/tested via getauxval(AT_SECURE). I inserted getauxval(AT_SECURE) into a test program, and it did indeed return 1 when it was running with any capabilities set and usable, the same as it would if running setuid, so capabilities have the same security protections as setuid.