Erica Windisch alerta que os namespaces de usuário do Linux podem não ser seguros o suficiente. Se um usuário root real teve a capacidade SYS_CAP_ADMIN removida, mas depois cria um namespace de usuário, a capacidade é restaurada para o usuário root falso. Antes de criar o namespace, 'mount' seria negado, mas após a criação, a chamada de sistema 'mount' funcionaria novamente de forma limitada. Isso é significativo o suficiente para que, dado um usuário root real e um kernel com namespaces de usuário, as capacidades do Linux possam ser completamente subvertidas.
A página de manual de user_namespaces confirma que o processo filho criado por clone(2) com CLONE_NEWUSER começa com um conjunto completo de capacidades no novo namespace de usuário. Os namespaces de usuário permitem interseções "interessantes" de modelos de segurança, concedendo capacidades de root completas ao novo namespace. Isso pode permitir que CLONE_NEWUSER use efetivamente CAP_NET_ADMIN sobre outros namespaces de rede, especialmente se os contêineres não estiverem em uso. Processos com CAP_NET_ADMIN têm uma grande superfície de ataque e resultaram em várias vulnerabilidades do kernel, potencialmente permitindo que um namespace de usuário não privilegiado ataque o subsistema de rede do kernel.
Demonstrações mostram que em um host com namespaces de usuário compilados, um usuário pode criar uma ponte usando ioctl com SIOCBRADDBR, embora definir capacidades de arquivo com cap_set_file falhe. O Ubuntu habilita CONFIG_USER_NS, mas o corrige para que o uso não privilegiado possa ser desabilitado com o sysctl unprivileged_userns_clone. A configuração do kernel tem como padrão 'n' para namespaces de usuário, recomendando MEMCG para limitar a memória de usuários não privilegiados.
Fonte: Hacker News · Resumido por HeadlinesBriefing