Política Targeted

Através da política targeted, cada sujeito e objeto roda em um domínio chamado unconfined_t exceto alguns serviços alvos que possuem políticas pré-definidas. Objetos que estão no domínio unconfined_t não possuem restrições e usam a segurança Linux padrão (DAC), ou seja, rodam como se não existisse o SELinux para realizar os controles de segurança. Os serviços que fazem parte da política targeted rodam em seus próprios domínios e são restritos à política para cada operação que realizam no sistema, dessa forma se esses serviços forem comprometidos ou de alguma maneira explorados por suas vulnerabilidades, os danos são limitados, podendo até ser controlados.
Como exemplo, o servidor web apache é protegido pela política targeted, e não poderá comprometer os outros serviços do sistema, como servidor de nomes, servidor ssh, arquivos privados de usuários, etc, conforme a política pré-definida. No formato padrão DAC, esta proteção não existe. Um bom exemplo disso é a vulnerabilidade no aplicativo gerenciador de conteúdo web chamado Mambo, que na versão 4.0.14 é vulnerável ao ataque descrito na CVE-2005-3738 [CVE 2005]. O SELinux é capaz de limitar esse ataque a ponto de torná-lo inútil [MCGUIRE 2007].

A política targeted é a padrão na maioria das distribuições Linux que usam SELinux, como Fedora 3 ou superior e Red Hat 4 ou superior. Atualmente existe uma lista muito grande de daemons e aplicativos que possuem uma política já definida pelos desenvolvedores do SELinux, não sendo necessária a criação ou modificações dessas políticas (a não ser em casos muito específicos, como uma situação não usual ou até mesmo um comportamento anormal de um aplicativo). Dentre os aplicativos para os quais já existem políticas targeted desenvolvidas de acordo com a política de referência [PEBENITO 2006] podem ser destacados: acct, ada, afs, aide, alsa, amanda, amavis, amtu, anaconda, apache, apcupsd, apm, application, apt, arpwatch, asterisk, audioentropy, authbind, authlogin, automount, avahi, awstats, backup, bind, bitlbee, bluetooth, bootloader, brctl, calamaris, canna, ccs, cdrecord, certwatch, cipe, clamav, clock, clockspeed, comsat, consolekit, consoletype, courier, cpucontrol, cron, cups, cvs, cyrus, daemontools, dante, dbskk, dbus, dcc, ddclient, ddcprobe, dhcp, dictd, distcc, djbdns, dmesg, dmidecode, dnsmasq, dovecot, dpkg, ethereal, evolution, exim, fail2ban, fetchmail, finger, firstboot, fstools, ftp, fusermount, games, gatekeeper, getty, gift, gnome, gpg, gpm, hal, hostname, hotplug, howl, i18n_input, imaze, inetd, init, inn, ipsec, iptables, irc, ircd, irqbalance, iscsi, jabber, java, kerberos, kismet, ktalk, kudzu, ldap, libraries, loadkeys, locallogin, lockdev, logging, logrotate, logwatch, lpd, lvm, mailman, mailscanner, miscfiles, modutils, mono, monop, mount, mozilla, mplayer, mrtg, mta, munin, mysql, nagios, nessus, netlabel, netutils, networkmanager, nis, nscd, nsd, ntop, ntp, nx, oav, oddjob, openca, openct, openvpn, pcmcia, pcscd, pegasus, perdition, portage, portmap, portslave, postfix, postgresql, postgrey, ppp, prelink, privoxy, procmail, publicfile, pxe, pyzor, qmail, quota, radius, radvd, raid, razor, rdisc, readahead, remotelogin, resmgr, rhgb, ricci, rlogin, roundup, rpc, rpcbind, rpm, rshd, rssh, rsync, rwho, samba, sasl, screen, selinuxutil, sendmail, setrans, setroubleshoot, slocate, slrnpull, smartmon, snmp, snort, soundserver, spamassassin, speedtouch, squid, ssh, stunnel, su, sudo, sxid, sysnetwork, sysstat, tcpd, telnet, tftp, thunderbird, timidity, tmpreaper, tor, transproxy, tripwire, tvtime, tzdata, ucspitcp, udev, uml, unconfined, updfstab, uptime, usbmodules, userdomain, userhelper, usermanage, usernetctl, uucp, uwimap, vbetool, virt, vmware, vpn, w3c, watchdog, webalizer, wine, xen, xfs, xprint, xserver, yam, zabbix e zebra.

Segundo [WALSH 2007], na versão 8 do Fedora Core Linux lançada em novembro de 2007, a política strict deixou de existir como uma política totalmente isolada da política targeted. Foi criada uma política híbrida onde tanto a política targeted quanto a strict é utilizada. No Fedora 8 é possível usar a política strict por usuário, adicionando o usuário em um domínio strict (domínio guest ouxguest , por exemplo), e esse usuário estará com limitações de acessos como era antigamente usando-se a política strict. Por padrão, os usuários serão criados ainda no domínio unconfined_t. Para remover totalmente a habilidade de processos executarem no domínio unconfined_t, pode-se remover o módulo unconfined com o comando ``semodule -r unconfined'' [WALSH 2007].