Con su cuenta de Red Hat puede acceder a su perfil de miembro y sus preferencias, además de a los siguientes servicios teniendo en cuenta su estado de cliente:
¿Aún no se ha registrado? Le ofrecemos varios motivos por los que debería hacerlo:
- Consulte artículos de la base de conocimiento, gestione casos de soporte y suscripciones, descargue actualizaciones y mucho más desde una misma ubicación.
- Consulte los usuarios de la organización, y edite la información, preferencias y permisos de sus cuentas.
- Gestione sus certificaciones de Red Hat, consulte el historial de exámenes y descargue logotipos y documentos relacionados con las certificaciones.
Con su cuenta de Red Hat puede acceder a su perfil de miembro, sus preferencias y otros servicios dependiendo de su estado de cliente.
Por seguridad, si está en un equipo de acceso público y ya ha terminado de utilizar los servicios de Red Hat, cierre sesión.Cerrar sesión
In our last post we talked about using Multi-Category Security (MCS) instead of Multi-Level Security (MLS) to provide isolation on systems with different levels of sensitivity. In this post we'll cover creating a more secure pipeline via containers.
A common pattern in MLS environments is to have a series of processes to guarantee the flow of information between networks at different levels, but to guarantee that no information gets accidentally leaked. These pipelines are sometimes called dirty word filters.
Imagine an MLS environment, where you have two networks connected to a machine. One of the networks is at Top Secret and the other network is at Secret. Now you might have a process downloading content from the Top Secret Network, another process, the filter process, examining the downloaded content and moving approved data from the Top Secret content to the Secret content. Finally you have a third process that is taking the Secret content and sending it out the Secret network.
We want to make sure that the data only flows in this direction, and guarantees that the Secret Process could not just listen to content on the TopSecret network, or go and examine the TopSecret content itself. These systems are usually controlled with SELinux and MLS labeling.
The problem with SELinux and MLS in this environment is that the policy is difficult to write, and you can end up with lots of accidental Access Vector Cache (AVC) messages (SELinux messages) just because of normal process activity. For example, every process on a standard SELinux system can see each other. The Secret Process executing a ps command, would generate SELinux errors indicating it tried to examine the Top Secret Process.
Using Podman and Containers to improve the process.
If you combine Podman containers with SELinux you can make it a lot simpler to confine and control the information flow. You can also make it more secure by taking advantage of additional security features in containers.
Use Podman to put the Top Secret, Filter, and Secret processes each into separate containers. The processes within the container will no longer see the other processes on the system, as well as the processes in the other containers.
Each container gets its own networks, meaning that Top Secret will only see the Top Secret Network, and Secret will only see the Secret network. In the Filter container, eliminate all networking. Control data flow by making the Top Secret data writable from the Top Secret Container, but read only from the Filter Container. The Filter Container can write to the Secret Content, and the Secret Container can only read the secret content.
From an SELinux point of view we can actually have the processes inside of the container run with the same type, but then control the information flow just using the MLS or MCS Labels.
The third part of this series described using a tool like Podman to separate each of the processes in your pipeline, makes them more secure and easier to write, and maintains the trustworthiness of an SELinux/MLS Environment. In the last part of the container security series we will focus on network traffic control in Red Hat OpenShift.
About the authors
Daniel Walsh has worked in the computer security field for over 30 years. Dan is a Senior Distinguished Engineer at Red Hat. He joined Red Hat in August 2001. Dan leads the Red Hat Container Engineering team since August 2013, but has been working on container technology for several years.
Lukas Vrabec is a Senior Software engineer & SELinux technology evangelist at Red Hat. He is part of Security Controls team working on SELinux projects focusing especially on security policies. Lukas is author of udica, the tool for generating custom SELinux profiles for containers and currently maintains the selinux-policy packages for Fedora and Red Hat Enterprise Linux distributions.
Simon Sekidde is a Solution Architect for the North America Red Hat Public Sector team specializing in the application of open source enterprise technologies for the Federal Department of Defense (DoD) customers.
Ben Bennett is a Senior Principal Software Engineer and is the group lead for the SDN, Routing, DNS, and Storage components of Red Hat OpenShift. He has more than 25 years of experience working with networking, distributed systems, and Linux.