.png)
Esta é uma schroot.confconfiguração típica que uso:
[label]
description=whatever
type=directory
personality=linux
preserve-environment=true
directory=/wherever
users=UserForSchrootOnly
profile=desktop_no_tmp
Nenhuma root-usersdiretriz.
Diretórios iniciais separados para schroot env, sem usar o /home do host.
Eu faço login com UserForSchrootOnlyo usuário do sistema operacional host nesses ambientes schroot. Eu costumo adicionar esse usuário ao /etc/sudoers.d/someConfarquivodentroschroot, com uma linha,
UserForSchrootOnly ALL=(ALL:ALL) ALL
Um dos meus objetivos desta configuração é ter um ambiente bastante isolado (não para auditoria de isolamento estrito, mas eficiente na prática), tanto através do schroot quanto usando um usuário do SO apenas para esse propósito e em nenhum outro lugar. Por outro lado, por razões práticas é muito mais fácil ter esse usuário dedicado também como sudoer, dentro do ambiente schroot, é claro.
Um caso de uso é executar um aplicativo de código fechado não confiável.
Minha preocupação é:
como UserForSchrootOnlyo usuário é um sudoer dentro do ambiente schroot, é possível haver algum comprometimento da segurança do sistema host devido a isso? Alguma maneira de usar a elevação sudo dentro do schroot env, para acessar algo fora do schroot ou fora UserForSchrootOnlydo diretório inicial do sistema host?
A página de manual do schroot.conf menciona que o acesso root ao chroot é um risco sério; Não estou preocupado com o mau comportamento do usuário. Minha preocupação é com o aplicativo de código fechado não confiável, aproveitando o usuário sudoer que ele executa.
Gostaria de salientar que embora este pareça ser um cenário ideal para um sandbox como o firejail, não consegui executar alguns aplicativos com ele, mesmo adicionando o --no-profileparâmetro. Além disso, outros cenários incluem aplicativos que precisam de bibliotecas mais recentes, então preciso configurar um ambiente schroot do Debian Testing ou Ubuntu para executar o aplicativo não confiável dentro dele.