Cgroups Xattr Security

Serge E. Hallyn said that within a user namespace (i.e., a virtual machine), a root user could not be allowed to write a security.capability extended attribute (xattr). If it could, then any user within that namespace could su to root, write the xattr, and execute the file with those security privileges on the host machine.

On the other hand, the root user on the host machine could absolutely be allowed to write a security.capability xattr because, of course, they're the root user. This is one of the many examples of ways in which security considerations require strange feature curtailment within virtual machines.

Nonetheless, if something behaves differently on the virtual machine than on the host, that represents a fundamental incompatibility that would affect things like software portability and reliability.

Serge was working on some code that would allow the virtual machine to believe the root user had written the security.capability xattr, while still protecting the host system. He hoped his code "allows a simple setxattr to work, allows tar/untar to work, and allows us to tar in one namespace and untar in another while preserving the capability, without risking leaking privilege into a parent namespace."

Eric W. Biederman liked the patch but said it was strange enough to need some very careful going-over before he'd send it along to the main tree; meanwhile, Serge wrote up a man page for Michael Kerrisk, to help testers understand what was going on.

Encrypting the Running Kernel

Tom Lendacky added support for Secure Memory Encryption (SME) to the x86 architecture. With his patch in place, if the kernel were compiled with SME enabled and booted with the command-line option mem_encrypt=on, then the running kernel would be encrypted.

The big controversy over this patch seemed to be how to turn it on and off. Borislav Petkov pointed out that if the user could specify mem_encrypt=on, it would make sense to support a mem_encrypt=off option, in case the user preferred not to encrypt the running kernel. However, Tom replied that, absent being explicitly turned on, the encryption simply would not occur. He was fine with documenting a mem_encrypt=off option, though, if that would make people happier.

However, Borislav said this wasn't his point at all. He simply felt that encryption should be enabled by default, and that if a user didn't want the feature enabled, they should give a mem_encrypt=off command-line argument to say so.

The discussion petered out there, but presumably any kernel developer would rather have their code enabled by default, instead of having to be specified by the user.

To Run an Unreadable File

Eric W. Biederman posted some code to prevent ptrace from running a file that did not have read privileges set. The apparently simple idea being, if you don't have permission to read the file, then how could you have permission to run the code you couldn't read?

However, Willy Tarreau did have an objection. He was concerned that people had been utilizing this very loophole for decades to block various rootkits from taking over their systems. He did a directory listing of his own bash, coreutils, ls, and telnet tools, showing that they were marked as executable without being readable.

Willy explained that certain rootkits did their mischief by copying and modifying the code in those fundamental utilities. By making them executable but not readable, Willy said he had blocked several rootkits over the years.

Meanwhile, Willy said, Eric's patch would make it difficult to debug any code that had to be traced through any of those utilities. He said, "So here I fear that we'll break strace at many places where strace precisely matters to debug things."

As an alternative, Willy suggested that Eric make his code controllable by a sysctl, so it could be turned on and off as needed.

Kees Cook said, however, that once Linux began to support executable-only memory, ptrace would again start to fail, so trying to hang on to it as long as possible didn't make much sense. Kees suggested just biting the bullet and doing it Eric's way.

In a surprise twist, Willy's objections were enough to give Eric second thoughts. He didn't want to break historical usage, so he redid his patch to simply produce a warning instead of disallowing running an unreadable file. Andy Lutomirski said he thought this was a better approach, too.