Apparmor nega vários processos desde uma mudança no kernel

Question

Por acaso encontrei um problema muito estranho. Estou executando o Ubuntu 17.10 em modo de desenvolvimento desde abril, e desde então tenho tentado permanecer no mais recente kernel RC para evitar problemas desagradáveis com suspensão e GPU que tive no meu Dell Precision.

Desde que instalei o 4.14-rc2, de repente perdi a conectividade WiFi. Depois de executar o bisect, reduzi o problema a um changeset no kernel que atualizou o Apparmor.

Olhando para journalctl -xe output, notei que muitos erros como esse apareceram:

Oct 27 14:45:48 precision audit[6088]: AVC apparmor="DENIED" operation="create" profile="/sbin/dhclient" pid=6088 comm="dhclient" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create"

Erros como esse também aconteceram com os processos mysqld , avahi-daemon e cups-browsed . Desativei os perfis para esses processos com o seguinte comando:

$ sudo ln -s /etc/apparmor.d/sbin.dhclient /etc/apparmor.d/disable
$ sudo apparmor_parser -R /etc/apparmor.d/sbin.dhclient 

E, boom, eu tenho WiFi de volta. Mas este é o caminho certo para lidar com essa situação? Devo modificar os perfis ou enviar um bug ao Launchpad sobre isso?

    

Answer 1

Sim, grandes mudanças na segurança do kernel (ou seja, apparmor) perderam o kernel 4.14-rc1 devido a alguns problemas, mas foram incluídos no kernel 4.14-rc2. E sim, há uma alteração não compatível com versões anteriores.

Eu mesmo, ou compilo o kernel com o apparmor desativado, ou simplesmente inicializo com ele desabilitado. ou seja, em '/ etc / default / grub ":

#GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 consoleblank=300"
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 consoleblank=300 apparmor=0"

O relatório de bug relacionado ao launchpad (mesmo que a descrição esteja um pouco errada) é aqui . Tem algum trabalho arounds.

Observe que esta pergunta e resposta podem acabar sendo suspensas, porque os kernels do release candidate não são suportados aqui.

EDITAR: atraso na entrada do relatório de erros:

% bl0ck_qu0te%