Lay a strong foundation by writing secure C and C++ utilities

Libraries and system utilities form the foundations on which larger projects are built. So it's critical to make sure they, in particular, are secure. That's why we recently introduced five new rules for C++ and C to detect broken authentication and access control in *nix systems. The new rules fall into three categories: account validity, granting permissions, and changing directories. 

For account validity, we've added a Security Vulnerability rule: S5832 - Account validity should be verified when authenticating users with PAM. It turns out that it's entirely possible for a user with an invalid account - one that is locked or expired - to authenticate successfully. As a utility writer, you need to verify both successful authentication and account validity. Otherwise, you could be letting in people who wish the organization harm, such as a former employee whose account has been disabled.

For setting permissions, we've added two new Security Hotspots rules. As a reminder, Security Hotspots are a separate class of security-related issues. When we raise a Security Hotspot on your code, we're not saying there's definitely something wrong that you need to fix. What we're saying is that there's the potential for something to be wrong depending on the context of the code, and human review is needed. The Security Hotspot rules we've added for permission setting are:

With both of these rules, the idea is to double-check that the permissions you've granted can't be tightened up. S2612 raises a Security Hotspot when you grant permissions to `others`. That one should be pretty obvious to most people, but the one about capabilities is a little more obscure. Linux "capabilities" allow you to assign narrow slices of `root`'s permissions to files (executables) and processes.

One of the dangers is that people may be less cautious about assigning a capability than full `root` privileges. Assigning narrow slices is better than granting full `root` access, but most capabilities can be exploited to escalate privileges to full `root` level, so they should be used with the same care as full `root`. 

For changing directories, we've added two more Security Hotspots:

Both of these rules revolve around thinking you've limited a process to a directory without actually accomplishing that. Theoretically, `chroot` changes the root directory of a process, thus "jailing" it away from the rest of the filesystem. But according to the description of S5802, 'many chroot function implementations don't modify the current working directory, thus the process still has access to unauthorized resources outside of the "jail"' if you don't also change your current working directory (`chdir`) to the new root directory.

So okay, let's say you `chdir` to the jail directory before you `chroot`. You're good, right? Not necessarily. `chdir` won't work if you don't have access to the directory. And that's what S5982 is about - making sure your `chdir` worked before you go any further. 

These new rules are available today in SonarQube and on SonarCloud. Together, they'll help you write more secure *nix utilities and libraries, laying a strong foundation for the applications that will be built on top of them.