4 Security Concepts #

The API and web interface frontends is the only part which must be accessible from public network. A SSL/TLS certificate is highly recommended.

The build environment is created by obsworker instances via the build script. Inside the build instances unverified and potentially harmful code is executed. Given that a user can run also any provided kernel the isolation must happen on VM layer. The only supported VM types, which are considered as secure are KVM and XEN VMs. The VMs prohibit any network access from the running instances. The build script is always creating a new file system, copies in all required data and executes the VM.

The build results get extracted directly from the block device. This is done to avoid mounting it which could be used to breach the host kernel in the file system code by crafting the used filesystem during build.

Every build also stores the used binaries inside of the _buildenv file. This can be used to re-create the build environment later, even when newer updates got released meanwhile. This requires however a maintenance setup to avoid that former releases get removed.

The build tools (like rpmbuild) are running usually as non-root user, but this is not a security instrument. It is only a quality mechanic to ensure that source packages are rebuildable without root permissions.

The source revision storage system is part of Open Build Service. The identification of sources still happens using MD5 sums for historic reasons. MD5 is considered to be still good enough for identifying a source, but it is known to be attackable. Recent versions of the osc command line tooling is sending therefore also a SHA256 sum in addition which is used to detect collisions by the source server.

Sources can reference other package sources via _link files. These can be pinned to a revision or to always using the latest one. That way underlying changes get merged automatically. This is useful for shared development and automated builds, but it should be avoided for base projects.

Authorization for write operations is done via the maintainer role on package or project level. On project level the projects are organized in namespaces which are defined via colons inside the project name. A maintainer role on a higher namespace grants the permission to claim maintainer role on any deeper project. Official projects should therefore be organized under their own top level namespaces (for example, openSUSE: namespace in our reference instance).

Signatures are used to proof the origin of a shipment independent of Open Build Service instance. Once the signd daemon has been enabled by the administrator, any binary result like RPM packages, images, containers, or meta data gets signed. All Open Build Service instances have a master key to sign results. This master key has two purposes: First, it is used for signing if a dedicated signing key can not be found. Second, it is used to encrypt dedicated project signing keys so that they can be stored inside of the projects instead of on the signing server. If a project does not have a signing key, the build server will search the parent projects. This follows the logic of the write permission handling.

An Open Build Service user (including the Open Build Service admin user) has only limited options to deal with the key setup. The user can create, delete, or extend the expire time of a key. It is not possible to import an external key. This guarantees that no key can be used outside of the Open Build Service instance to sign Open Build Service content.

A SSL certificate is derived from the keys when needed (for example, for secure boot).

GPG keypairs are created by the signd daemon. Therefore, it is recommend to run this daemon on a separated and protected host. The master keypair should exist only on this signd host. Any further created keypair is not stored on the signd instance, instead the private part is encrypted with the master key and transferred to the Open Build Service backend. Thus, the signd instance is stateless and needs no recurring backups after initial setup. All keypairs (public and private parts) are therefore part of the backup of the Open Build Service backend servers. The sign executable transfers just the hash to be signed (not the entire file content) together with the encrypted private key to signd. The daemon decrypts the private key with the master key, creates the signature, and sends it back to the client. The returned signature is applied to the binary by the sign executable afterwards.

A compromised backend would still result in a serious security incident since any content can be signed with any project key. The private keys are not compromised themselves though.

Public zones are areas where any code under user control is running.

The Demilitarized Zone contains services which interact with the public zone directly.

The internal zone is running service which are supposed to work without further external dependency.

The Open Build Service workers are running in an own isolated network. They access only source and binary servers from internal zone.

The signing server is supposed to be the most isolated service. It is supposed to be stateless after initial setup. Avoid to enable any remote access.

Figure 4.1: Trust Zones of Open Build Service #