Comments: FuseSecurityRequirements-Jan2017.docx


Here are my comments on the FuseSecurityRequirements-Jan2017.docx as requested at the security working group meeting last week.



= General =

"Snappy" was the original name of Ubuntu Core, it's not really used to describe the product. Ubuntu Core 16 is the proper name of the product, which is a long-term-support (LTS) release.

= Constraints =

"The boot process is assumed to be secure, i.e., system is assumed to have come up securely without any exposure or tampering of the Hardware Root of Trust."

Not all systems have a hardware root of trust. Depending on the host OS and hardware, the system may not have support for TPM-based trusted boot. For instance, the Dell Gateways, while including a TPM, don't support trusted boot. That said, they do support (and enforce) UEFI Secure Boot via Ubuntu Core 16.

2) Attacks on Secrets

Is the available weak default password described on the wiki anywhere? How does this password restrict access to sensitive data? Can you give an actual example?

6) Attacks on Embedded Components

"Remediation: By default, disable network-facing inbound TCP ports for all microservices".

If all microservices disable inbound TCP ports, doesn't that prevent incoming REST API requests from being received by the services?

7) Attacks on Excessive Privilege

"Every microservice runs as root in Snappy; there is no other role or permission level identified for Fuse. As such, the solution does not offer adequate protection against, e.g., a rogue administrator, who performs unauthorized functions maliciously or by accident (due to a misconfiguration of the system)."

While it's true that services delivered via snaps run as root on Ubuntu Core 16, it should be noted that services are confined/sandboxed and thus don't have the same privileges they would on a traditional Linux system. Likewise when the microservices are being run inside Docker containers.

8) Attacks on Installation and Patching

"There are no controls in place (e.g., code signing) to prevent an attacker from introducing a malicious installation or patch package during or after deployment. In particular, microservices are not code signed, nor is there any integrity checking of the Manifest used for deploying them to Docker containers."

I'll point out that if a microservice was delivered as snap as opposed to a docker container, the code is signed and verified during installation/update. Also snaps deliver their code via a read-only filesystems, making such attacks more difficult.

= Recommendations =

2) Encrypt sensitive data at rest (i.e., data held in repositories and files by Fuse microservices)

Who defines what data is sensitive, the end customer? I would think encryption of data such as that held by core data would be an optional feature that a customer could choose to enable, but wouldn't be a default (especially given the potential impact on latency and/or performance).

Join to automatically receive all group messages.