Security and boundaries
Though he clearly stated that he is "not a security person", James Bottomley nevertheless came to the 2014 Linux Security Summit (LSS) to give a keynote presentation. On August 18 in Chicago, Bottomley gave a wide-ranging talk that looked at a number of security topics—from some recent vulnerabilities to general philosophical security principles.
Bottomley is a well-known kernel developer, however, who maintains the SCSI subsystem and PA-RISC architecture. He is also on the Linux Foundation Technical Advisory Board (TAB). In addition, he has worked on the UEFI Secure Boot issue, which required him to spend a "bunch of time arguing" with UEFI people about Secure Boot. He would like to have given a keynote about that topic, he said, but Matthew Garrett beat him to it by doing so at LSS in 2012.
![[James Bottomley]](https://static.lwn.net/images/2014/lss-bottomley-sm.jpg)
Instead, Bottomley said that he would look at some of the consequences of Secure Boot. The key problem with Secure Boot is one of security boundaries—also known as "who trusts what". Secure Boot gives absolute control to the platform owner and puts no trust into the operating system (OS). For systems where the hardware and the OS are all delivered together, that works fine, but Linux doesn't fit that model.
In addition, if the OS is untrusted, how can it make use of the root of trust that Secure Boot creates, he asked. The Linux solution is to "put a hack in UEFI" to create its own root of trust. That hack is shim, which subverts the Secure Boot root of trust. That is a "really bad idea" for any security system, but the Linux community had no other choice, he said.
That leads to a question for UEFI, he said: "how should we do this properly?" A more cooperative boundary of trust would be one way, but the people who put together Secure Boot did not consider the possibility that the trust boundary may not be absolute.
Modern operating systems have a similar problem. It used to be that the OS had absolute control over networking. Now, though, on some systems, any user can start up a KVM instance that allows access to the entire network layer. And users can bind to ports with port numbers less than 1024, which is something that is assumed to be impossible in lots of different places. The boundary of trust has now shifted, he said.
Bottomley then moved into an "aside about containers". In terms of the boundary of trust, they are like hypervisors. In addition, they are no more or less secure than hypervisors, he said, and arguing about which is more secure is like arguing about where to put the holes in a colander. The customers of Parallels (where Bottomley is the CTO) have shown that any attacks come via the web interface of some application that is running on the system. Real-world attacks do not try to break either container or hypervisor security. Both have shifted security boundaries, though, and coping with that means changing the way we trust things.
For law enforcement purposes, predictive security is Orwellian; you can't put someone in jail simply because you believe they will commit a crime. Similarly, predictive models in computing are currently flawed as well. His email to certain recipients is blocked because his IP address is in the same net block as those of spammers. Once a predictive gets something wrong, it is quite difficult to reverse it, as well.
Prevention works, he said, since locks do prevent (some) theft. But using atmospheric sedation to prevent crimes of violence goes too far. One of those preventative measures is prudent, while the other damages utility. Security is about finding the balance between utility and prevention. The saying about the only truly secure computer is one that is not connected to the network (or, better still, never turned on) is true, but not terribly useful.
Who is being served?
Security developers need to consider who they are serving. Bottomley wants security that serves him, not some "admin in the IT [information technology] dungeon". His company requires password rotation every 90 days, which is one of the biggest security problems in IT, he said. He has ten or so devices that all use that password, each of which needs to be updated when it changes.
Some people can keep track of frequently changing passwords, but most can't, so they write their password down. He can literally wander around in the office at work and find sticky notes with password-like strings, all but one of which are crossed out. Password rotation is a case where IT is pushing its problems of logging and verification onto him and other users. When you implement a security solution that pushes the problem onto users, you become part of the problem, not part of the solution, he said.
This is actually a problem we can blame on Microsoft, he said, since its Active Directory service recommends password rotation in its documentation on security policies.
A "brilliant example" of a security tool that does consider who it is serving is the Firefox password manager. He can keep five or so password strings in his head, but that doesn't scale to the hundreds of sites that require him to create an account with a password—each of which is supposed to be unique. The password manager allows him to have that many unique passwords; he only needs to protect the single password that encrypts the passwords stored by the manager. In fact, he said, banks and other sites that try to prevent him from storing the account credentials are making a mistake—one that he rectifies with some GreaseMonkey scripts to remove the HTML that does so.
Two-factor authentication is something that many people think is helpful to security, but it has a flawed implementation, he said. Because two-factor authentication typically uses dongles, it doesn't work well for people with multiple accounts. Having ten different dongles to deal with multiple accounts is impossible to manage; if there were just one that worked for all of the different services, then two-factor authentication might be useful. The design behind two-factor authentication is fine, he said, but the implementation has interoperability problems.
Blocking people with unusual patterns of access can be an effective security technique, as long as the patterns truly are unusual. He noted that the BBC has to consider Finland as a part of the UK because the train system in the UK contracted its WiFi service to a company in Finland. Previously, the BBC's content was only available for streaming within the UK, based on the IP address of the connection. Since train travelers all appeared to be coming from IP addresses in Finland, and wanted to be able to watch their favorite shows on the train, the BBC decided that particular access pattern had to be supported. Similar types of "unusual" access patterns will exist in other contexts as well.
Linux security
Turning to Linux security, Bottomley said that if the talk had been in April, he might have claimed that there were no significant vulnerability problems with Linux. But May brought Heartbleed and the kernel tty privilege escalation bug, which changed the outlook substantially.
Both flaws were essentially buffer overflows, which is a problem that has been known "forever", he said. "Is C to blame?". It is a beautiful, simple language, but programmers still can't seem to work with buffers correctly in it.
Another part of the problem may be that developers are often so enamored with their new features that they turn them on by default. The SSL heartbeat functionality was not particularly critical and was actually used very little, but it was turned on everywhere, which is what made Heartbleed into an episode of major panic.
There are static checkers that can find buffer overflows and other similar problems. They tend to produce lots of false positives, however, so someone has to be paid to "sit in a room and get rid of them". That has been done for the kernel, he said, so that when he gets handed a report from the static checkers, he is generally sure that it will be a real problem. Those checkers are catching things in the kernel before they make their way into a release, which is a good thing. OpenSSL is now running static checkers and paying someone to eliminate the false positives.
Plan B
Heartbleed taught us to "always have a Plan B", he said, but we may not always follow that. For example, the entire security of the internet is dependent on two unsolved mathematical problems: fast methods to calculate discrete logarithms and do prime factorization. If either gets solved, SSL/TLS goes "up in smoke", taking the security of our communication over the internet with it. The question he would leave with the assembled security developers is this: "What is our Plan B?"
There are lots of conspiracy theorists who believe those problems have already been solved by the NSA, but he is confident that is not the case. He has a PhD in a math-related field (quantum field theory) and feels sure that "no mathematician could resist the lure" of revealing that those problems had been solved. They would eventually drop that information "over beer", and he would have heard about it.
He would argue that for SSL/TLS, there is no Plan B. Some might say that elliptic curve cryptography (ECC) could replace the other two hard math problems if they were solved, but that is not the case. Elliptic curve problems can all be transformed into one of the other two, so breaking those would break ECC as well.
Conclusion
If the security boundary moves, embrace it, Bottomley said in his conclusion. Security systems must also consider the consequences of their implementation along with who they are serving. Developers should "get clear in your mind" who that solution is meant to serve.
As the password-rotation tale showed, bowing to enterprise requirements can lead to a loss of security. The best security helps a willing consumer do something that they want do; the Firefox password manager is a good example of that. He also encouraged the audience to be thinking about that Plan B for internet security.
[ Thanks to the Linux Foundation for sponsoring my travel to Chicago for LSS. ]
| Index entries for this article | |
|---|---|
| Security | Keynotes |
| Conference | Linux Security Summit/2014 |