E outro desafio que estou obtendo para criar uma vm:
ao criar uma VM aparece a seguinte mensagem:

Não foi possível completar a instalação: "Cannot access storage file '/root/.local/share/libvirt/images/debian11-1.qcow2' (as uid:107, gid:107): Permissão negada"

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager
[11:54]
agradeço em quem puder tentar ajudar

Instalando o PostgreSQL

O PostgreSQL está nos repositórios do Fedora, então podemos usar o DNF pela linha de comando ou algum gerenciador de pacotes (como o dnfdragora) para fazer a instalação dos pacotes postgresql e postgresql-server.

Usando a linha de comando:
sudo dnf install postgresql postgresql-server

Configuração inicial do PostgreSQL

sudo postgresql-setup initdb

Iniciando e habilitando o serviço do PostgreSQL

sudo systemctl start postgresql

Opcional: habilitar o serviço para iniciar com o sistema

sudo systemctl enable postgresql

Fazendo o login no shell como administrador do PostgreSQL

sudo su - postgres

Criando o primeiro banco de dados

Com o login do usuário postgres, podemos criar o banco de dados

createdb banco-teste

Fazendo a conexão com o banco-teste

Agora podemos nos conectar ao banco criado anteriormente

psql -d banco-teste

Controlando o acesso ao cluster do PostgreSQL (PG Cluster)

Não se esqueça, você precisa estar logado, no shell, com o usuário postgres

sudo su - postgres

Ainda no shell do usuário postgres, você pode criar um usuário para acessar o cluster:

createuser leandro -P

Agora você pode criar um banco de dados colocando o usuário leandro como proprietário.

createdb banco-leandro --owner leandro

Editando o arquivo de configuração do PostgreSQL

É hora de adicionar a regra de acesso para o usuário leandro. Para isso, edite o arquivo ~/data/pg_hba.conf com seu editor preferido (vou usar o editor vim).
O diretório ~ representa o diretório inicial (home) do usuário postgres, que é o /var/lib/pgsql - por ter acesso administrativo, o usuário postgres pode escrever dentro do diretório.

Vamos editar o arquivo:
vim ~/data/pg_hba.conf

Na seção local, adicione a linha para o usuário leandro

# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all leandro md5
local all all peer

Reinicie o serviço do PostgreSQL com o seu usuário comum (não o postgres)

sudo systemctl restart postgresql

Fazendo a conexão ao banco do novo usuário

Com o seu usuário comum, conecte-se ao banco-leandro do usuário leandro

psql -d banco-leandro -U leandro

Permitindo conexões TCP/IP para o novo usuário

Para usar programas cliente de PostgreSQL e não ter que administrar o banco pela linha de comando, temos que liberar o usuário leandro para fazer conexões através de TCP/IP - tanto no localhost quanto remotamente.

Com o usuário postgres, edite novamente o arquivo ~/data/pg_hba.conf

sudo su - postgres
vim ~/data/pg_hba.conf

Libere o acesso ao usuário no localhost ou outros hosts/IPs necessários

# IPv4 local connections:
host all leandro localhost md5
host all all 127.0.0.1/32 ident

Não se esqueça de reiniciar o PostgreSQL (com seu usuário comum!)

sudo systemctl restart postgresql

Configurando o DBeaver CE para acesso ao banco

Tutorial de instalação do DBeaver: https://fedorabr.org/index.php?p=/discussion/305/instalando-o-cliente-de-bancos-de-dados-dbeaver-community-edition

Selecione PostgreSQL para iniciar a configuração, depois coloque os detalhes da conexão com o usuário leandro, faça o download do driver e teste a conexão.

Correções e melhorias são coisas muito bem-vindas. Abraços, pessoal!

instalando o MariaDB

sudo dnf install mariadb-server

Inicie o serviço do MariaDB

sudo systemctl start mariadb

Se quiser que o serviço MariaDB inicie junto com o sistema, habilite-o com o Systemd

sudo systemctl enable mariadb

Configurando o MariaDB

Faça a configuração inicial do MariaDB para criar a senha do usuário root

sudo mysql_secure_installation


[leandro@fedora ~]$ sudo mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none): <Enter> 
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] y
New password: 
Re-enter new password: 
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
 ... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!

Fazendo o login no MariaDB

mysql -u root -p

Criando um usuário administrador no MariaDB

É melhor criar um usuário com poderes de administrador do que ficar usando o usuário root para fazer as tarefas no banco de dados, você pode fazer isso pela linha de comando:

MariaDB [(none)]> grant all privileges on *.* to leandro@localhost identified by 'senha';

Depois você pode fazer o login com seu novo usuário e administrar o banco de dados à vontade.

mysql -u seuusuario -p

Administrando o MariaDB pela interface gráfica

Se você não gosta ou não quer administrar seu servidor de banco de dados pela linha de comando, você pode instalar algum cliente de interface gráfica para isso. Existem várias opções, mas eu recomendo duas: phpMyAdmin e DBeaver.

Para instalar o phpMyAdmin, use a pilha LAMP - tutorial: https://fedorabr.org/index.php?p=/discussion/47/tutorial-lamp-no-fedora

Tutorial de instalação do DBeaver: https://fedorabr.org/index.php?p=/discussion/305/instalando-o-cliente-de-bancos-de-dados-dbeaver-community-edition/

phpMyAdmin:

DBeaver:

Na primeira parte da série SELinux , vimos como habilitar e desabilitar o SELinux e como alterar algumas configurações de política usando valores booleanos. Nesta segunda parte, falaremos sobre contextos de segurança de arquivos e processos.

Para atualizar sua memória do tutorial anterior, um contexto de segurança de arquivo é um tipo e um contexto de segurança de processo é um domínio.

Nota
Os comandos, pacotes e arquivos mostrados neste tutorial foram testados no CentOS 7. Os conceitos permanecem os mesmos para outras distribuições.

Neste tutorial, estaremos executando os comandos como usuário root, a menos que seja indicado de outra forma. Se você não tiver acesso à conta root e usar outra conta com privilégios sudo, precisará preceder os comandos com o sudo.

Criando contas de usuário de teste

Primeiro, vamos criar quatro contas de usuário para demonstrar os recursos do SELinux à medida que avançamos.

• joao
• pedro
• maria
• ana

Você deve estar logado com o usuário root . Vamos executar o seguinte comando para adicionar a conta joao :

$ useradd joao

Em seguida, executamos o comando “passwd” para criar/alterar sua senha:

$ passwd joao

A saída solicitará uma nova senha. Uma vez fornecida, a conta estará pronta para o login:

Changing password for user regularuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Vamos criar as outras contas também:

$ useradd pedro
$ passwd pedro

$ useradd maria
$ passwd maria

$ useradd ana
$ passwd ana

SELinux para processos e arquivos

O objetivo do SELinux é proteger como os processos acessam arquivos em um ambiente Linux. Sem o SELinux, um processo ou aplicativo como o Apache será executado no contexto do usuário que o iniciou. Portanto, se o seu sistema for comprometido por um aplicativo não autorizado que esteja sendo executado no usuário root, o aplicativo poderá fazer o que quiser, pois o root possui direitos abrangentes em todos os arquivos.

O SELinux tenta dar um passo adiante e eliminar esse risco. Com o SELinux, um processo ou aplicativo terá apenas os direitos necessários para funcionar e NADA mais. A política do SELinux para o aplicativo determinará a quais tipos de arquivos ele precisa acessar e a quais processos ele pode fazer a transição. As políticas do SELinux são escritas por desenvolvedores de aplicativos e enviadas com a distribuição Linux que a suporta. Uma política é basicamente um conjunto de regras que mapeia processos e usuários aos seus direitos.

Começamos a discussão desta parte do tutorial, entendendo o significado dos contextos e domínios do SELinux .

A primeira parte da segurança coloca um rótulo em cada entidade no sistema Linux. Um rótulo é como qualquer outro atributo de arquivo ou processo (proprietário, grupo, data de criação etc.); mostra o contexto do recurso. Então, o que é um contexto? Simplificando, um contexto é uma coleção de informações relacionadas à segurança que ajuda o SELinux a tomar decisões de controle de acesso. Tudo em um sistema Linux pode ter um contexto de segurança: uma conta de usuário, um arquivo, um diretório, um daemon ou uma porta podem ter seus contextos de segurança. No entanto, o contexto de segurança vai significar coisas diferentes para diferentes tipos de objetos.

Contextos de arquivos do SELinux

Vamos começar entendendo os contextos de arquivo do SELinux. Vejamos a saída de um comando ls -l regular no diretório /etc.

$ ls -l /etc/*.conf

Isso nos mostrará uma saída familiar:

... 
-rw-r--r--. 1 root root    19 Aug 19 21:42 /etc/locale.conf
-rw-r--r--. 1 root root   662 Jul 31  2013 /etc/logrotate.conf
-rw-r--r--. 1 root root  5171 Jun 10 07:35 /etc/man_db.conf
-rw-r--r--. 1 root root   936 Jun 10 05:59 /etc/mke2fs.conf
...

Simples, certo? Vamos agora adicionar o -Z:

$ ls -Z /etc/*.conf

Agora temos uma coluna extra de informações após a propriedade do usuário e do grupo:

...
-rw-r--r--. root root system_u:object_r:locale_t:s0    /etc/locale.conf
-rw-r--r--. root root system_u:object_r:etc_t:s0       /etc/logrotate.conf
-rw-r--r--. root root system_u:object_r:etc_t:s0       /etc/man_db.conf
-rw-r--r--. root root system_u:object_r:etc_t:s0       /etc/mke2fs.conf
...

Esta coluna mostra os contextos de segurança dos arquivos. Diz que um arquivo foi rotulado com seu contexto de segurança quando você tem essas informações disponíveis. Vamos dar uma olhada em um dos contextos de segurança.

-rw-r--r--. root    root  system_u:object_r:etc_t:s0       /etc/logrotate.conf

O contexto de segurança é esta parte:

system_u:object_r:etc_t:s0

Existem quatro partes e cada parte do contexto de segurança é separada por dois pontos (:). A primeira parte é o contexto do usuário do SELinux para o arquivo. Discutiremos os usuários do SELinux mais tarde, mas, por enquanto, podemos ver que é system_u. Cada conta de usuário do Linux é mapeada para um usuário do SELinux e, nesse caso, o usuário raiz que possui o arquivo é mapeado para o usuário system_u SELinux. Esse mapeamento é feito pela política do SELinux.

A segunda parte especifica a função SELinux , que é object_r . Para revisar as funções do SELinux, consulte o primeiro artigo do SELinux.

O mais importante aqui é a terceira parte, o tipo de arquivo listado aqui como etc_t . Esta é a parte que define a que tipo de arquivo ou diretório pertence. Podemos ver que a maioria dos arquivos pertence ao tipo etc_t no /etc, você pode pensar no tipo como uma espécie de "grupo" ou atributo para o arquivo: é uma maneira de classificar o arquivo.

Também podemos ver que alguns arquivos podem pertencer a outros tipos, como o locale.conf que tem um tipo locale_t. Mesmo quando todos os arquivos listados aqui tiverem o mesmo usuário e proprietário do grupo, seus tipos poderão ser diferentes.

Como outro exemplo, vamos verificar os contextos de tipo para diretórios pessoais do usuário:

$ ls -Z /home

Os diretórios pessoais terão um tipo de contexto diferente: user_home_dir_t

drwx------. maria      maria      unconfined_u:object_r:user_home_dir_t:s0      maria
drwx------. root           root           system_u:object_r:lost_found_t:s0 lost+found
drwx------. joao    joao    unconfined_u:object_r:user_home_dir_t:s0      joao
drwx------. restricteduser ana unconfined_u:object_r:user_home_dir_t:s0      ana
drwx------. switcheduser   switcheduser   unconfined_u:object_r:user_home_dir_t:s0      pedro
drwx------. sysadmin       sysadmin       unconfined_u:object_r:user_home_dir_t:s0      sysadmin

A quarta parte do contexto de segurança, s0, tem a ver com segurança multinível ou MLS. Basicamente, essa é outra maneira de aplicar a política de segurança do SELinux e essa parte mostra a sensibilidade do recurso (s0). Falaremos brevemente sobre sensibilidade e categorias posteriormente. Para a maioria das configurações completas do SELinux, os três primeiros contextos de segurança são mais importantes.

Contextos do processo SELinux

Vamos agora falar sobre os contextos de segurança do processo.
Inicie os serviços Apache e SFTP. Instalamos esses serviços no primeiro tutorial do SELinux.

$ systemctl start httpd
$ systemctl start vsftpd 

Podemos executar o ps comando com alguns sinalizadores para mostrar os processos Apache e SFTP em execução no nosso servidor:

$ ps -efZ | grep 'httpd\|vsftpd'

Mais uma vez, o sinalizador -Z é usado para exibir os contextos do SELinux. A saída mostra o usuário executando o processo, o ID do processo e o ID do processo pai:

 system_u:system_r:httpd_t:s0            root        7126    1       0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7127    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7128    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7129    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7130    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7131    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:ftpd_t:s0-s0:c0.c1023 root        7209    1       0 16:54 ?        00:00:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7252 2636  0 16:57 pts/0 00:00:00 grep --color=auto httpd\|vsftpd

O contexto de segurança é esta parte:

 system_u:system_r:httpd_t:s0

O contexto de segurança possui quatro partes: usuário, função, domínio e sensibilidade. O usuário, a função e a sensibilidade funcionam exatamente como os mesmos contextos para os arquivos (explicados na seção anterior). O domínio é exclusivo para processos.

No exemplo acima, podemos ver que alguns processos estão em execução no domínio httpd_t, enquanto um está em execução no domínio ftpd_t.

Então, o que o domínio está fazendo pelos processos? Isso fornece ao processo um contexto para execução. É como uma bolha em torno do processo que a limita. Diz ao processo o que pode e o que não pode fazer. Esse confinamento garante que cada domínio do processo possa atuar apenas em certos tipos de arquivos e nada mais.

Usando esse modelo, mesmo que um processo seja invadido por outro usuário ou processo malicioso, o pior que pode fazer é danificar os arquivos aos quais ele tem acesso. Por exemplo, o daemon vsftp não terá acesso aos arquivos usados por, por exemplo, sendmail ou samba. Essa restrição é implementada no nível do kernel: é aplicada à medida que a política do SELinux é carregada na memória e, portanto, o controle de acesso se torna obrigatório.

Convenções de nomenclatura

Antes de prosseguirmos, aqui está uma observação sobre a convenção de nomenclatura do SELinux. Os usuários do SELinux possuem o sufixo "_u", as funções com o sufixo "_r" e os tipos (para arquivos) ou domínios (para processos) com o sufixo "_t".

Como os processos acessam recursos

Até agora, vimos que arquivos e processos podem ter contextos diferentes e que são restritos a seus próprios tipos ou domínios. Então, como um processo é executado? Para executar, um processo precisa acessar seus arquivos e executar algumas ações neles (abrir, ler, modificar ou executar). Também aprendemos que cada processo pode ter acesso apenas a certos tipos de recursos (arquivos, diretórios, portas, etc.).

O SELinux estipula essas regras de acesso em uma política. As regras de acesso seguem uma estrutura padrão de instrução allow:

 allow  : {  };

Já falamos sobre domínios e tipos. Classe define o que o recurso realmente representa (arquivo, diretório, link simbólico, dispositivo, portas, cursor etc.)

Aqui está o que essa declaração de permissão genérica significa:

• Se um processo é de determinado domínio
• E o objeto de recurso que está tentando acessar é de certa classe e tipo
• Então permita o acesso
• Senão negar acesso

Para ver como isso funciona, vamos considerar os contextos de segurança do daemon httpd em execução no nosso sistema:

 system_u:system_r:httpd_t:s0     7126 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7127 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7128 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7129 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7130 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7131 ?        00:00:00 httpd

O diretório inicial padrão do servidor da web é /var/www/html. Vamos criar um arquivo nesse diretório e verificar seu contexto:

$ touch /var/www/html/index.html
$ ls -Z /var/www/html/*

O contexto do arquivo para o nosso conteúdo da web será httpd_sys_content_t :

 -rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

Podemos usar o sesearch comando para verificar o tipo de acesso permitido para o daemon httpd:

$ sesearch --allow --source httpd_t --target httpd_sys_content_t --class file

Os sinalizadores usados com o comando são bastante auto-explicativos: o domínio de origem é httpd_t, o mesmo domínio em que o Apache está sendo executado. Estamos interessados nos recursos de destino que são arquivos e têm um contexto de tipo httpd_sys_content_t. Sua saída deve ficar assim:

 Found 4 semantic av rules:
   allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock open } ;
   allow httpd_t httpd_content_type : file { ioctl read getattr lock open } ;
   allow httpd_t httpd_content_type : file { ioctl read getattr lock open } ;
   allow httpd_t httpdcontent : file { ioctl read write create getattr setattr lock append unlink link rename execute open } ;

Observe a primeira linha:

 allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock open } ;

Isso indica que o httpd daemon (o servidor Apache) possui controle de I/O, lê, obtém atributo, bloqueia e abre acesso a arquivos do tipo httpd_sys_content. Nesse caso, nosso index.html tem o mesmo tipo.

Indo um passo adiante, vamos primeiro modificar a página web (/var/www/html/index.html). Edite o arquivo para conter este conteúdo:

Em seguida, alteraremos a permissão do diretório /var/www/ e seu conteúdo, seguido por uma reinicialização do daemon httpd:

$ chmod -R 755 /var/www
$ service httpd restart

Em seguida, tentaremos acessá-la a partir de um navegador:

Nota
Dependendo de como o servidor estiver configurado, talvez seja necessário habilitar a porta 80 no firewall do IPTables para permitir o tráfego HTTP de entrada de fora do servidor. Não entraremos em detalhes sobre a ativação de portas no IPTables aqui. Existem outros artigos meus aqui no fórum que abordam sobre o assunto.

Por enquanto, tudo bem. O daemon httpd está autorizado a acessar um tipo específico de arquivo e podemos vê-lo ao acessar pelo navegador. Em seguida, vamos tornar as coisas um pouco diferentes, alterando o contexto do arquivo. Nós usaremos o comando chcon para isso. A –type sinalização para o comando permite especificar um novo tipo para o recurso de destino. Aqui, estamos alterando o tipo de arquivo para var_t.

$ chcon --type var_t /var/www/html/index.html

Podemos confirmar a alteração de tipo:

$ ls -Z /var/www/html/

 -rwxr-xr-x. root root unconfined_u:object_r:var_t:s0   index.html

Em seguida, quando tentamos acessar a página (ou seja, o daemon httpd tenta ler o arquivo), você pode receber um erro Forbidden ou a página genérica “Testing 123” do CentOS:

Então, o que está acontecendo aqui? Obviamente, agora algum acesso está sendo negado, mas de quem é esse acesso? No que diz respeito ao SELinux, o servidor está autorizado a acessar apenas certos tipos de arquivos e var_t não é um desses contextos. Como alteramos o contexto do arquivo index.html para var_t, o Apache não pode mais lê-lo e obtemos um erro.

Para fazer as coisas funcionarem novamente, vamos mudar o tipo de arquivo com o comando restorecon a opção -v mostra a alteração dos rótulos de contexto:

$ restorecon -v /var/www/html/index.html

 restorecon reset /var/www/html/index.html context unconfined_u:object_r:var_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0

Se tentarmos acessar a página agora, ele mostrará o texto "Esta é uma página de teste" novamente.

Este é um conceito importante para entender: garantir que arquivos e diretórios tenham o contexto correto é essencial para garantir que o SELinux esteja se comportando como deveria. Veremos um caso de uso prático no final desta seção, mas antes disso, vamos falar sobre mais algumas coisas.

Herança de contexto para arquivos e diretórios

O SELinux impõe algo que podemos chamar de "herança de contexto". O que isso significa é que, a menos que especificado pela política, processos e arquivos são criados com o contexto de seus pais.

Portanto, se tivermos um processo chamado “proc_a” gerando outro processo chamado “proc_b”, o processo gerado será executado no mesmo domínio que “proc_a”, a menos que especificado de outra forma pela política do SELinux.

Da mesma forma, se tivermos um diretório com o tipo "some_context_t", qualquer arquivo ou diretório criado nele terá o mesmo contexto de tipo, a menos que a política indique o contrário.

Para ilustrar isso, vamos verificar os contextos do diretório /var/www/:

$ ls -Z /var/www

O diretório html dentro de /var/www/ tem o contexto do tipo httpd_sys_content_t. Como vimos antes, o arquivo index.html dentro dele tem o mesmo contexto (ou seja, o contexto do pai):

 drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html 

Essa herança não é preservada quando os arquivos são copiados para outro local. Em uma operação de cópia, o arquivo ou diretório copiado assumirá o contexto de tipo do local de destino. No snippet de código abaixo, estamos copiando o arquivo index.html (com o contexto do tipo "httpd_sys_content_t") para o diretório /var:

$ cp /var/www/html/index.html /var/

Se verificarmos o contexto do arquivo copiado, veremos que ele mudou para var_t, o contexto de seu diretório pai atual:

$ ls -Z /var/index.html

 -rwxr-xr-x. root root unconfined_u:object_r:var_t:s0   /var/index.html

Essa mudança de contexto pode ser substituída pela --preserver=contexto cláusula no comando cp.

Quando arquivos ou diretórios são movidos, os contextos originais são preservados. No comando a seguir, estamos movendo o /var/index.html para o diretório /etc/:

$ mv /var/index.html /etc/ 

Quando verificamos o contexto do arquivo movido, vemos que o contexto var_t foi preservado no diretório /etc/:

$ ls -Z /etc/index.html 

 -rwxr-xr-x. root root unconfined_u:object_r:var_t:s0   /etc/index.html 

Então, por que estamos tão preocupados com os contextos dos arquivos? Por que esse conceito de copiar e mover é importante? Pense bem: talvez você tenha decidido copiar todos os arquivos HTML do servidor da web para um diretório separado na pasta raiz. Você fez isso para simplificar o processo de backup e também para aumentar a segurança: você não deseja que nenhum hacker adivinhe facilmente onde estão os arquivos do seu site. Você atualizou o controle de acesso do diretório, alterou o arquivo de configuração da web para apontar para o novo local, reiniciou o serviço, mas ainda não funciona. Talvez você possa ver os contextos do diretório e seus arquivos como a próxima etapa de solução de problemas. Vamos executá-lo como um exemplo prático.

SELinux em ação: testando um erro de contexto de arquivo

Primeiro, vamos criar um diretório nomeado www na raiz. Também criaremos uma pasta chamada html em www.

$ mkdir -p /www/html 

Se executarmos o comando ls -Z, veremos que esses diretórios foram criados com o contexto default_t :

$ ls -Z /www/

 drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 html

Em seguida, copiamos o conteúdo do diretório /var/www/html para /www/html:

$ cp /var/www/html/index.html /www/html/

O arquivo copiado terá um contexto de default_t. Esse é o contexto do diretório pai.

Agora, editamos o arquivo httpd.conf para apontar para esse novo diretório como a pasta raiz do site. Também teremos que modificar os direitos de acesso para este diretório.

$ vi /etc/httpd/conf/httpd.conf 

Primeiro comentamos o local existente para a raiz do documento e adicionamos uma nova diretiva DocumentRoot a /www/html:

 # DocumentRoot "/var/www/html"
DocumentRoot "/www/html" 

Também comentamos a seção de direitos de acesso para a raiz do documento existente e adicionamos uma nova seção:

#
#    AllowOverride None
    # Allow open access:
#    Require all granted
#


    AllowOverride None
    # Allow open access:
    Require all granted

Deixamos a localização do diretório cgi-bin como está. Não estamos entrando na configuração detalhada do Apache, aqui nós apenas queremos que nosso site funcione para fins do SELinux.

Por fim, reinicie o daemon httpd:

$ service httpd restart 

Depois que o servidor for reiniciado, o acesso à página da web nos dará o mesmo erro “403 Proibido” (ou a página padrão “Teste 123”) que vimos antes.

O erro está ocorrendo porque o contexto do arquivo index.html foi alterado durante a operação de cópia. Ele precisa ser alterado de volta ao seu contexto original (httpd_sys_content_t).

Mas como nós fazemos isso?

Alterando e restaurando contextos de arquivo SELinux

Em um exemplo de código anterior, vimos dois comandos para alterar o conteúdo do arquivo: chcon e restorecon. Usar chcon é uma medida temporária. Você pode usá-lo para alterar temporariamente os contextos de arquivo ou diretório para solucionar problemas de erros de negação de acesso. No entanto, esse método é apenas temporário: um sistema de arquivos chamado novamente ou executando o comando restorecon reverterá o arquivo para seu contexto original.

Além disso, a execução chcon requer que você conheça o contexto correto para o arquivo; o sinalizador --type especifica o contexto para o destino. restorecon não precisa disso especificado. Se você executar restorecon, o arquivo terá o contexto correto reaplicado e as alterações serão permanentes.

Mas se você não conhece o contexto correto do arquivo, como o sistema sabe qual contexto aplicar quando é executado restorecon?

Convenientemente, o SELinux "lembra" o contexto de cada arquivo ou diretório no servidor. No CentOS 7, os contextos dos arquivos já existentes no sistema são listados no arquivo /etc/selinux/targeted/contexts/files/file_contexts. É um arquivo grande e lista todos os tipos de arquivos associados a todos os aplicativos suportados pela distribuição Linux. Contextos de novos diretórios e arquivos são registrados no arquivo /etc/selinux/targeted/contexts/files/file_contexts.local. Portanto, quando executamos o comando restorecon, o SELinux pesquisará o contexto correto de um desses dois arquivos e o aplicará ao destino.

O trecho de código abaixo mostra uma extração de um dos arquivos:

$ cat /etc/selinux/targeted/contexts/files/file_contexts 

...
/usr/(.*/)?lib(/.*)?    system_u:object_r:lib_t:s0
/opt/(.*/)?man(/.*)?    system_u:object_r:man_t:s0
/dev/(misc/)?agpgart    -c      system_u:object_r:agp_device_t:s0
/usr/(.*/)?sbin(/.*)?   system_u:object_r:bin_t:s0
/opt/(.*/)?sbin(/.*)?   system_u:object_r:bin_t:s0
/etc/(open)?afs(/.*)?   system_u:object_r:afs_config_t:s0
...

Para alterar permanentemente o contexto do nosso arquivo index.html /www/html, precisamos seguir um processo de duas etapas.

• Primeiro, executamos o comando semanage fcontext. Isso gravará o novo contexto no arquivo /etc/selinux/targeted/contexts/files/file_contexts.local. Mas não irá rotular novamente o arquivo. Faremos isso nos dois diretórios.

$ semanage fcontext --add --type httpd_sys_content_t "/www(/.*)?"

$ semanage fcontext --add --type httpd_sys_content_t "/www/html(/.*)?"

Para garantir, podemos verificar o banco de dados de contexto do arquivo (observe que estamos usando o arquivo file_contexts.local):

$ cat /etc/selinux/targeted/contexts/files/file_contexts.local

Você deve ver os contextos atualizados:

# This file is auto-generated by libsemanage
# Do not edit directly.

/www(/.*)?    system_u:object_r:httpd_sys_content_t:s0
/www/html(/.*)?    system_u:object_r:httpd_sys_content_t:s0

Em seguida, executaremos o comando restorecon. Isso irá rotular novamente o arquivo ou diretório com o que foi gravado na etapa anterior:

$ restorecon -Rv /www

Isso deve redefinir o contexto em três níveis: o diretório /www de nível superior , o diretório /www/html abaixo dele e o arquivo index.html em /www/html:

restorecon reset /www context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0
restorecon reset /www/html context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0
restorecon reset /www/html/index.html context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0

Se agora tentarmos acessar a página da web, ela deverá funcionar.

Existe uma ferramenta bacana chamada matchpathcon que pode ajudar a solucionar problemas relacionados ao contexto. Este comando examinará o contexto atual de um recurso e o comparará com o listado no banco de dados de contexto do SELinux. Se diferente, sugerirá a alteração necessária. Vamos testar isso com o arquivo /www/html/index.html,Usaremos -V fleg que verifica o contexto:

$ matchpathcon -V /www/html/index.html

A saída matchpathcon deve mostrar que o contexto é verificado.

 /www/html/index.html verified.

Para um arquivo rotulado incorretamente, a mensagem dirá qual deve ser o contexto:

/www/html/index.html has context unconfined_u:object_r:default_t:s0, should be system_u:object_r:httpd_sys_content_t:s0 

Transição de Domínio

Até agora, vimos como os processos acessam os recursos do sistema de arquivos. Agora veremos como os processos acessam outros processos.

Transição de domínio é o método em que um processo altera seu contexto de um domínio para outro. Para entendê-lo, digamos que você tenha um processo chamado proc_a em execução dentro de um contexto de contextta_t. Com a transição do domínio, proc_a pode executar um aplicativo (um programa ou um script executável) chamado app_x que geraria outro processo. Esse novo processo pode ser chamado proc_b e pode estar em execução no domínio contextb_t. Tão efetivamente, contextta_t está fazendo a transição para contextb_t através do app_x. O executável app_x está funcionando como um ponto de entrada para contextb_t.

O caso de transição de domínio é bastante comum no SELinux. Vamos considerar o processo vsftpd em execução no nosso servidor. Se não estiver em execução, podemos executar o comando systemctl start vsftpd para iniciar o daemon.

A seguir, consideramos o processo systemd. Este é o ancestral de todos os processos. Essa é a substituição do processo de inicialização do System V e é executada dentro de um contexto de init_t. :

$ ps -eZ  | grep init

 system_u:system_r:init_t:s0         1 ?        00:00:02 systemd
system_u:system_r:mdadm_t:s0      773 ?        00:00:00 iprinit 

O processo em execução no domínio init_t é de curta duração: invocará o executável binário /usr/sbin/vsftpd, que possui um contexto de tipo ftpd_exec_t . Quando o executável binário é iniciado, ele se torna o daemon vsftpd e é executado no domínio ftpd_t.

Podemos verificar os contextos de domínio dos arquivos e processos:

$ ls -Z /usr/sbin/vsftpd

Saída:

-rwxr-xr-x. root root system_u:object_r:ftpd_exec_t:s0 /usr/sbin/vsftpd

Verificando o processo:

$ ps -eZ | grep vsftpd

Saída:

system_u:system_r:ftpd_t:s0-s0:c0.c1023 7708 ? 00:00:00 vsftpd

Portanto, aqui o processo em execução no domínio init_t está executando um arquivo binário com o tipo ftpd_exec_t. Esse arquivo inicia um daemon no domínio ftpd_t.

Essa transição não é algo que o aplicativo ou o usuário possa controlar. Isso foi estipulado na política do SELinux que é carregada na memória quando o sistema é inicializado. Em um servidor que não seja o SELinux, o usuário pode iniciar um processo alternando para uma conta mais poderosa (desde que tenha o direito de fazê-lo). No SELinux, esse acesso é controlado por políticas pré-escritas. E esse é outro motivo pelo qual o SELinux implementa o Controle de Acesso Obrigatório.

A transição de domínio está sujeita a três regras estritas:

• O processo pai do domínio de origem deve ter a permissão de execução do aplicativo entre os dois domínios (este é o ponto de entrada).
• O contexto do arquivo para o aplicativo deve ser identificado como um ponto de entrada para o domínio de destino.
• O domínio original deve ter permissão para fazer a transição para o domínio de destino.

Tomando o exemplo do daemon vsftpd acima, vamos executar o comando sesearch com diferentes opções para verificar se o daemon está em conformidade com essas três regras.

Primeiro, o domínio de origem init_t precisa ter permissão de execução no aplicativo de ponto de entrada com o contexto ftpd_exec_t. Portanto, se executarmos o seguinte comando:

$sesearch -s init_t -t ftpd_exec_t -c file -p execute -Ad 

O resultado mostra que os processos no domínio init_t podem ler, obter atributos, executar e abrir arquivos do contexto ftpd_exec_t:

 Found 1 semantic av rules:
   allow init_t ftpd_exec_t : file { read getattr execute open } ; 

Em seguida, verificamos se o arquivo binário é o ponto de entrada para o domínio de destino ftpd_t:

$ sesearch -s ftpd_t -t ftpd_exec_t -c file -p entrypoint -Ad

E de fato é:

 Found 1 semantic av rules:
   allow ftpd_t ftpd_exec_t : file { ioctl read getattr lock execute execute_no_trans entrypoint open } ; 

E, finalmente, o domínio de origem init_t precisa ter permissão para fazer a transição para o domínio de destino ftpd_t:

$ sesearch -s init_t -t ftpd_t -c process -p transition -Ad

Como podemos ver abaixo, o domínio de origem tem essa permissão:

Found 1 semantic av rules:
   allow init_t ftpd_t : process transition ;

Domínios não confinados

Quando introduzimos o conceito de domínios, o comparamos a uma bolha hipotética em torno do processo: algo que estipula o que o processo pode ou não fazer. É isso que limita o processo.

O SELinux também possui processos que são executados em domínios não confinados. Como você pode imaginar, processos não confinados teriam todos os tipos de acesso no sistema. Mesmo assim, esse acesso completo não é arbitrário: o acesso total também é especificado na política do SELinux.

O exemplo de um domínio de processo não confinado seria unconfined_t. Esse é o mesmo domínio que os usuários conectados executam seus processos por padrão. Falaremos sobre usuários e seus acessos para processar domínios nas seções subsequentes.

Conclusão

Cobrimos alguns conceitos muito importantes do SELinux. O gerenciamento de contexto de arquivo e processo está no centro de uma implementação bem-sucedida do SELinux. Como veremos na próxima e última parte desta série, há outra peça do quebra-cabeça restante: o usuário do SELinux.

Até a próxima e ultima parte do artigo.

- hosts: all
  gather_facts: no
  tasks:
   - name: Download Katello CA rpm
     get_url:
       url: http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm
       dest: /tmp/katello-ca-consumer-latest.noarch.rpm
       mode: '0440'

   - name: install Katello CA rpm from a local file
     yum:
       name: /tmp/katello-ca-consumer-latest.noarch.rpm
       state: present

   - name: Register with activationkey
     redhat_subscription:
       state: present
       activationkey: rhel7_base
       org_id: example

   - name: Enable all RHSM repositories
     rhsm_repository:
       name: '*'
       state: enabled

   - name: Install Packages
     yum:
       name: 
         - katello-host-tools 
         - katello-host-tools-tracer 
         - katello-agent
         - insights-client
         - puppet
       state: present

   - name: Start and enabled service Puppet agent
     systemd:
       name: puppet
       state: started
       enabled: true

   - name: Start and enabled service katello agent
     systemd:
       name: goferd
       state: started
       enabled: true

   - name: upgrade all packages
     yum:
       name: '*'
       state: latest

Vou usar o sistema CentOS 7 para fazer a demonstração. A primeira a ser feita é liberar o acesso por SSH na máquina convidada (Guest), no caso, a máquina virtual CentOS que está rodando no virt-manager.

No terminal da máquina virtual, edite o arquivo /etc/ssh/sshd_config
Obs.: eu uso sudo, mas você pode usar o login de root se preferir. E também pode usar outro editor de textos (como nano, jed ou outro que seja mais amigável para a sua necessidade). Não se prenda ao editor usado no tutorial.

sudo vi /etc/ssh/sshd_config

Remova o comentário da linha "Port 22" (remova o caractere #). Você pode mudar o número da porta também, e é aconselhável que o faça a menos que tenha algum redirecionamento de portas antes de chegar à sua máquina. Salve o arquivo.

Criando a rede para conectar a máquina virtual

Caso você não tenha criado a rede antes, desligue a máquina virtual e crie uma rede no virt-manager.

systemctl poweroff -i

Abra o virt-manager e clique no menu "Editar" -> "Detalhes da conexão"

Na aba "Redes Virtuais", clique no botão + para adicionar uma nova
rede.

Passo 1 de 4

Coloque o nome que desejar na nova rede e clique em "Avançar".

Passo 2 de 4

Nas definições de IPv4, as opções padrão nos servirão para o tutorial. Você pode testar algo mais detalhado se quiser se aprofundar no assunto.

Passo 3 de 4

Não é necessário configurar o IPv6 para o tutorial.

Passo 4 de 4

Selecione a opção "Encaminhado à rede física", o destino e o modo.
Escolha o destino "Qualquer dispositivo físico" e o modo "NAT" e clique em "Concluir".

Configurando a máquina virtual para usar a nova rede

Na janela principal do virt-manager, clique no sistema centos7 (ou no sistema em que você estiver configurando) e clique no botão "Abrir".

Nas configurações da máquina, clique em "NIC", escola a rede apropriada no item "Fonte de Rede" e clique em "Aplicar".

Clique no console gráfico e no Play para iniciar a máquina virtual.

Verificando a rede da máquina virtual

Faça login no console da máquina virtual e certifique-se de obter um IP via DHCP (ou configure IP Fixo se desejar, isso foge do meu escopo no momento).

sudo dhclient

Verifique seu IP com o comando abaixo:

ip a

Acessando a VM por SSH

No sistema Host, abra um emulador de terminal e digite o comando
ssh seuusuario@192.168.100.149
Adapte o comando acima às suas necessidades

Criando um nome amigável para o host

Para facilitar seu login via SSH, você pode criar um nome para a máquina virtual no arquivo /etc/hosts da sua máquina Host.

sudo vi /etc/hosts
Obs.: use seu editor preferido

Após configurar o nome no arquivo de hosts, você poderá acessar o servidor na máquina virtual usando o nome criado no lugar do IP, facilitando a digitação e possibilitando o uso da tecla TAB para autocompletar o comando:

ssh seuusuario@centos

Acessando o servidor virtual pelo gerenciador de arquivos

Abra seu gerenciador de arquivos preferido (vou usar o Nautilus aqui) para acessar o servidor. Para isso, digite o caminho sftp://centos no campo de endereços do gerenciador de arquivos (você deve encontrar a opção aí no seu gerenciador preferido).

Você pode adicionar um marcador para o servidor no seu gerenciador de arquivos.

Até o próximo tutorial!

Faça o download do repositório MySQL em https://dev.mysql.com/downloads/repo/yum/

Instalando o repositório do MySQL

Para instalar o repositório, abra seu gerenciador de arquivos e faça a instalação do pacote usando seu gerenciador de pacotes preferido.

Se você preferir (meu caso), pode instalar pela linha de comando:

Instalando o MySQL Server Community

Com o seu gerenciador de pacotes predileto, busque pelo mysql-community-server e faça a instalação.

Claro, se preferir, instale pela linha de comando:

Iniciando o serviço do MySQL

sudo systemctl start mysqld

Se quiser que o servidor MySQL inicie junto com o sistema, habilite-o no Systemd

sudo systemctl enable mysqld

Configurando o MySQL

Durante a instalação do mysql-community-server, uma senha aleatória é gerada para o usuário root. Você precisa recuperar a senha inicial para poder configurar uma nova senha. Use o comando abaixo:

sudo grep 'A temporary password is generated' /var/log/mysqld.log | tail -1

Use a senha gerada na configuração do MySQL:

sudo mysql_secure_installation

No campo da senha do root, coloque a senha gerada no comando anterior e altere a senha do root. Mas atenção: use uma senha forte (maiúsculas, minúsculas, números e símbolos), pois o validador de senhas do MySQL é exigente e eu NÃO RECOMENDO que você mude isso.

Após a configuração inicial você poderá logar no MySQL com a nova senha.

Criando um usuário administrador

Faça login no MySQL com o root

mysql -u root -p

Crie um usuário para tarefas administrativas (é melhor do que usar o root para tudo)

use mysql;
create user 'leandro'@'localhost' identified by 'S3nh4@forte';
grant all privileges on *.* to 'leandro'@'localhost';
flush privileges;
exit

Faça o login com o seu usuário administrador

mysql -u leandro -p

Administrando o servidor com ferramentas gráficas

Você pode instalar ferramentas gráficas para administrar seus bancos de dados. Minha preferida é DBeaver Community Edition - tutorial de instalação: https://fedorabr.org/index.php?p=/discussion/305/instalando-o-cliente-de-bancos-de-dados-dbeaver-community-edition/