 |
gildot |
 |
| |
| | Servidores partilhados e o modelo de segurança do Unix | | |  | Contribuído por pls em 24-12-03 17:54
do departamento Crónica | |  | |  | | |  “Tudo ou nada” é a questão que assombra o modelo de segurança do Unix. Em vários cenários, ou se tem acesso de root ao sistema, ou uma série de operações não são possíveis de realizar. Quando se partilham responsabilidades de administração em máquinas com vários clientes, este modelo tende a revelar-se frágil e simplista para um mundo tendencialmente complexo.
Alternativas? Eu escolhi uma... venham as opiniões.
| | | | | | As respostas do Unix a estas limitações ao longo dos últimos 30 anos foram tão diversificadas como a panóplia de problemas que a vida real tende a proporcionar a administradores de sistemas.
- O “Sudo”/“Calife” permitem ultrapassar alguns dos obstáculos, mas são um tremendo risco de segurança (a história de problemas associados a escapadelas para shells, e leitura de ficheiros a que não se pretendia dar acesso, a partir de editores, e não só, ganharam o direito a várias páginas nos manuais de segurança).
- “Access Control Lists” (ACL) permitem um controlo maior sobre as permissões de ficheiros no “filesystem” e são uma opção para resolver alguns dos problemas em alguns dos cenários. As ACL estão disponíveis em alguns Unix comerciais (pelo menos no Irix e Solaris), no FreeBSD e no Windows (NT e descendentes)... Não sei o estado do Linux nesta matéria.
- Os “secure levels” (do kernel) disponíveis nos BSD (não conheço o equivalente em Linux) ajudam em determinadas circunstâncias, permitindo limitar o acesso a determinados ficheiros (“flags” de ficheiro “imutável”, “append only”, “undeletable”) mesmo ao user id 0 (associado ao “root”).
- Aplicações e acessos “chrooted” permitem em vários cenários uma resposta eficaz e cabal ao problema. Mas são, em alguns casos, um pincel de configurar, manter e actualizar. Durante anos resolveram-me praticamente todos os problemas que tinha.
No entanto há circunstâncias em que é preciso dar aos co-administradores de um determinado serviço um poder quase ilimitado. E digo “quase” porque queremos dar todo o poder de administração sobre os recursos associados a um determinado cliente e aos seus serviços, mas queremos que todos esse “poder” esteja limitado às áreas desse cliente. Não interfira com os processos, filesystem e serviços do cliente do lado. Uma coisa é certa, se o cliente vai ter a capacidade para actualizar e reconfigurar os seus “daemons”, aplicar “patches”, e fazer manutenção completa das suas aplicações necessita de um acesso de “root”. Menos que isso e fica tremendamente limitado na sua capacidade de fazer determinadas operações que podem ser absolutamente vitais para o serviço que presta.
A solução é encarcerar “userlands”? Depois de literalmente passar demasiadas horas a tentar encontrar uma eventual solução para o que eram as minhas necessidades concretas lá cheguei a um modelo que parece responder. Utilizo FreeBSD com os serviços em “jails”.
Sem querer escrever um “howto” sobre as minhas configurações, até porque não tenho o tempo para o fazer agora, quero deixar umas “pistas” sobre como montar “jails” no FreeBSD e deixar uma ideia geral sobre como funcionam. Podem encontrar um manual completo no “handbook” em www.freebsd.org .
Em termos genéricos, o kernel do FreeBSD suporta “jails” sem necessidade de ser recompilado. É conveniente, mas não necessário para efeitos de testes, configurar alguns aspectos do funcionamento das “jails” com uns “sysctls” (nomeadamente definir se a comunicação entre as “jails” e o sistema “anfitrião” se faz exclusivamente através de “IP”, ou se suportam “sockets”, “ipx”, etc, se há semáforos de “system V” disponíveis às aplicações que correm na jail, etc).
Testar o sistema não é complicado. Uma única nota prévia: desliguem todos os daemons que estiverem a correr (ssh, inetd, apache, sendmail, etc) antes de executarem o teste...
Três simples passos para testar o ambiente de “jail” O primeiro passo para montar uma “jail” é compilar a “userland” (toda neste exemplo... idealmente deve ser instalado o indispensável para o serviço que a jail vai prestar) do FreeBSD ("cd /usr/src; make world DESTDIR=/mount/point/da/jail") e copiar a dita cuja para o respectivo “mount point” (make installworld DESTDIR=/mount/point/da/jail).
O segundo passo é criar a “/etc” (cd /usr/src/etc; make distribution DESTDIR=/mount/point/da/jail NO_MAKEDEV_RUN=yes) da “jail”, respectivos “devices” (cd /mount/point/da/jail/dev; sh MAKEDEV jail) e um “falso kernel” (só para as aplicações que o procuram: ln -sf dev/null kernel).
O terceiro passo é criar um alias para a placa de rede (com o IP que a “jail” vai utilizar: ifconfig fxp0 alias 192.168.1.1) e montar o “filesystem” (mount -t procfs proc /mount/point/da/jail/proc). E entrar na dita cuja em “em quase single user mode” (jail /mount/point/da/jail hostnamedajail 192.168.1.1 /bin/tcsh)...
E agora? Dentro da “jail” o “root” está encarcerado (“chrooted” no que respeita ao “filesystem” e aos processos sobre os quais pode exercer controle ou aos quais pode enviar sinais) e incapaz de exercer qualquer efeito sobre o resto do sistema. Podem ser montados todos os daemons na jail associados a um determinado serviço e/ou cliente. Todas as permissões do sistema ficam “disponíveis” dentro da “jail”, que conta com os seus utilizadores, grupos, etc.
Dar conectividade (total ou parcial) para o exterior à “jail” através do “natd” é em tudo semelhante à configuração de um firewall e gateway para uma rede interna. Cada “jail” pode ser tratada como uma máquina numa DMZ, com conectividade limitada, túneis de acesso para os vários serviços, etc.
No meu caso particular (ou seja nos meus servidores) utilizo uma jail como front-end (protegida com o firewall do sistema) a correr o “squid” e redirectores para os servidores de backend nas várias “jails” de cada cliente (ou conjuntos de clientes). Serviços comuns a várias “jails” (dns, mail, etc) correm à parte, isolados e encarcerados, como se fossem serviços de uma rede interna.
Performance e espaço em disco. Obviamente que há um impacto em ter “várias userlands” (o kernel é comum a todas as “jails”), cada uma com os seus “daemons” próprios (apache, mysql, etc) a correr. Mas o impacto é bastante menor que utilizar “máquinas virtuais” (usermode Linux, vmware e afins). A vossa métrica pode variar, mas eu corro muitos sites e serviços em “jails” (Várias dezenas deles! Incluindo o www.startux.org , www.maisturismo.pt , euro2004.portugalinsite.pt , mail para mais de 500 clientes, etc) e francamente em termos de CPU o impacto é mínimo, em termos de memória e disco é aceitável (para o efeito pretendido... ambos são baratos...).
As vantagens em termos de administração de sistemas são óbvias… instalar patches na “userland” e “ports” em todas as “jails” em simultâneo é trivial e há apenas um kernel a manter. A nível de segurança é equivalente a ter todos os “daemons” e serviços “chrooted”, com a vantagem de poderem ser “mexidos” por clientes que tenham administração de sistemas interna (como acessos de root, o que significa muita flexibilidade).
O busílis da questão é mesmo se em termos económicos esta abordagem faz sentido. Para o meu caso faz. Contas feitas, para prestar os serviços que presto, aos clientes que tenho, e lhes dar acesso semelhante aos seus próprios sistemas esta foi a melhor abordagem que encontrei.
PLS < NTT DoCoMo:Linux é bom(TM) | Feliz Natal > | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | (...)“Access Control Lists” (ACL) permitem um controlo maior sobre as permissões de ficheiros no “filesystem” [...]Não sei o estado do Linux nesta matéria.(...)
O kernel 2.6 tem suporte completo para ACLs em filesystems que o suportem (ext2/ext3/reiserfs/jfs/xfs pelo menos). Para o 2.4 existem patches que algumas distribuições já incluem nos seus "kerneis" há algum tempo (pelo menos a SuSE) mas que outras teimam em não incluir (como a Red Hat, que por acaso agora já inclui na sua versão Enterprise mas não no Fedora) por existirem alguns problemas no 2.4 quando se junta NFS com ACLs (no 2.6 isto está resolvido).
(...)Os “secure levels” (do kernel) disponíveis nos BSD (não conheço o equivalente em Linux) ajudam em determinadas circunstâncias, permitindo limitar o acesso a determinados ficheiros (“flags” de ficheiro “imutável”, “append only”, “undeletable”) mesmo ao user id 0 (associado ao “root”).
Não conheço até onde vai o suporte dos BSDs nesta matéria mas o Linux fornece algo desse género com algumas limitações, basta fazer "man chattr".
(...)Mas o impacto é bastante menor que utilizar “máquinas virtuais” (usermode Linux, vmware e afins)(...)
Seria excelente se houvesse algo para transformar um x86 numa espécie de "Poor Man's zSeries". Uma espécie de SO vmware que funcionasse sem requerer um sistema operativo, virtualizando tudo (ou pelo menos o que interessa) na máquina de modo a poder correr vários SOs em simultâneo e suportando alocação dinâmica de recursos a cada um (exactamente aquilo que o z/OS faz).
-- Carlos Rodrigues
|
| | | | | | | | Não conheço até onde vai o suporte dos BSDs nesta matéria mas o Linux fornece algo desse género com algumas limitações, basta fazer "man chattr". O chattr só actua se correres sistemas de ficheiros ext2/ext3. O que esse programa faz é basicamente um enable ou disable a bits especiais que existem apenas nesse tipo de sistema de ficheiros, logo não é uma uma alternativa fiavel para quem use ( muita gente ) reiserFS ou outro.
O sistema do freebsd, não actua dessa maneira, é kernel based, logo muito mais poderoso (pelo menos nesse aspecto).
|
| | | | Parece-me um mecanismo interessante, que permite confinar programas, dando-lhes o mínimo de privilégios que eles precisam (princípio do privilégio mínimo).
Inicialmente desenvolvido como um protótipo pela NSA (www.nsa.gov/selinux), foi integrado no linux 2.6. Permite fazer coisas giras, como tirar os poderes de super-user ao root (este modelo não tem super-users). Serve essencialmente para controlar que tipos de informação um 'user' com determinado nível de segurança consegue aceder, previnir que programas leiam determinados dados, interferir com outros programas, etc. Este tipo de modelos é usado há bastante tempo pelos militares.
A config por omissão no 2.6, é manter o modelo tradicional do unix (root como super-user, etc), mas isso pode ser mudado. :)
Espero que em breve possa ser usado em sistemas de produção.
|
| | | | | | Até há uns tempos os MAC em Linux implicavam uma séria penalização de performance. Esperemos que isso não seja mais uma realidade ou pelo menos que desligar os MAC implique ter a performance de volta (digo isto porque, por exemplo, a Red Hat tem como objectivo incluir o SELinux na próxima versão do Fedora).
-- Carlos Rodrigues
|
| | | | Sem duvida penso que o principal sistema e o mais fiavel será a utilização dos modos nao ditos do kernel mas sim os modos privigiliados da arch Intel IA-32 aka ring 0,1,2,3. Usar as alternativas que o hardware nos dá e não somente o que quase todos os sistemas operativos nos dão super-user ou user-mode respectivamente ring 0 e 3 é o metodo ideal. As ACL são um sistema com muito futuro mas ainda com mtos passos para dar. FreeBSD conseguiu estar á frente dos ditos free OSs.
|
| | | | | | FreeBSD conseguiu estar á frente dos ditos free OSs.
E não só... :-)
PLS
|
| | | | | o que quase todos os sistemas operativos nos dão super-user ou user-mode respectivamente ring 0 e 3 Isto esta completamente errado, o root num sistema operativo unix/linux (normal) nunca tem ring 0 acess, tem sim ring 3, todos os rings para cima de 3 (logo mais priviligiados) so estão disponiveis no kernel space e não na userland
Duvidas ? passa o GDB por um programa root, e verifica o valor de %cs, %ds, ou então tenta ler um bocado sobre kernel internals para não dizeres disparates desses.
As ACL são um sistema com muito futuro mas ainda com mtos passos para dar. Acls são usadas à largos anos e estão disponiveis em todos os sistemas operativos considerados Trusted, logo dai supoe-se que são uteis e poderosas, o unico problema são as pessoas que não as sabem usar.
FreeBSD conseguiu estar á frente dos ditos free OSs. Onde ? Como ? Falas do que ? Não digo que por default não possa passar muitos, agora também te digo que quem tiver olhos na cara e saiba usar uma coisa named "RSBAC" + "Linux kernel" descobre um mundo completamente diferente de segurança e largamente superior ao vosso freebsd default world. In the RSBAC version 1.2.2, the following modules are included. Please note that all modules are optional. They are described in detail in an extra text.
MAC
Bell-LaPadula Mandatory Access Control (compartments limited to a number of 64)
FC
Functional Control. A simple role based model, restricting access to security information to security officers and access to system information to administrators.
SIM
Security Information Modification. Only security administrators are allowed to modify data labeled as security information
PM
Privacy Model. Simone Fischer-Hübner's Privacy Model in its first implementation. See our paper on PM implementation (43K) for the National Information Systems Security Conference (NISSC 98)
MS
Malware Scan. Scan all files for malware on execution (optionally on all file read accesses or on all TCP/UDP read accesses), deny access if infected. Currently the Linux viruses Bliss.A and Bliss.B and a handfull of others are detected. From v1.2.0, a generic interface allows to replace the scanning engine through a kernel module at runtime. Also see our paper on Approaches to Integrated Malware Detection and Avoidance (34K) for The Third Nordic Workshop on Secure IT Systems (Nordsec'98)
FF
File Flags. Provide and use flags for dirs and files, currently execute_only (files), read_only (files and dirs), search_only (dirs), secure_delete (files), no_execute (files), add_inherited (files and dirs), no_rename_or_delete (files and dirs, no inheritance) and append_only(files and dirs).
Only FF security officers may modify these flags.
RC
Role Compatibility. Defines roles and types for each target type (file, dir, dev, ipc, scd, process). For each role, compatibility to all types and to other roles can be set individually and with request granularity. For administration there is a fine grained separation-of-duty.
Granted rights can have a time limit. Please also refer to the Nordsec 2002 RC Paper for the detailed model design and specification.
AUTH
Authorization enforcement. Controls all CHANGE_OWNER requests for process targets, only programs/processes with general setuid allowance and those with a capability for the target user ID may setuid. Capabilities can be controlled by other programs/processes, e.g. authentication daemons.
ACL
Access Control Lists. For every object there is an Access Control List, defining which subjects may access this object with which request types.Subjects can be of type user, RC role and ACL group. Objects are grouped by their target type, but have individual ACLs. If there is no ACL entry for a subject at an object, rights are inherited from parent objects, restricted by an inheritance mask. Direct (user) and indirect (role, group) rights are accumulated. For each object type there is a default ACL on top of the normal hierarchy. Group management has been added in version 1.0.9a. Granted rights and group memberships can have a time limit.
CAP
Linux Capabilities (new in 1.2.0). For all users and programs you can define a minimum and a maximum Linux capability set ("set of root special rights"). This lets you e.g. run server programs as normal user, or restrict rights of root programs in the standard Linux way.
JAIL
Process Jails (new in 1.2.1). This module adds a new system call rsbac_jail, which is basically a superset of the FreeBSD jail system call. It encapsulates the calling process and all subprocesses in a chroot environment with a fixed IP address and a lot of further restrictions.
RES
Linux Resources (new in 1.2.2). For all users and programs you can define a minimum and a maximum Linux process resource set (e.g. memory size, number of open files, number of processes per user). Internally, these sets are applied to the standard Linux resource flags.
Quanto ao topico inicial estou convicto que com as features da rsbac é possivel de se fazer o mesmo que o pls referiu, manter 1 nivel de segurança mais elevado, e não "carregar" tanto o sistema.
|
| | | | Não quero "flames" mas queria me referir aos niveis privigiliados da arquitectura ia-32 e nao da virtualização que os OSs fazem deles. Nao sei se percebeste isso. :) pelos vistos nao.
|
| | | | Os níveis priveligiados em ia-32 nada têm que ver com os previlégios dos users. Mesmo o root corre em userlad, o post anterior explica isso. Já agora, "userland" é ring 2 ou 3, dependendo da implementação. De qualquer forma, é do senso comum que o mecanismo de protecção ia-32 é uma salsada completa e não resolve todos os problemas. Se queres virtualização completa, tens uma séria penalização de performance. Que eu me lembre alguns sistemas operativos continuam a usar stacks mapeadas em descriptors com permissão de execução e áreas de dados com a mesma política. Outros exemplos comuns são implementações deficientes ou "trapalhonas" de serviços baseados em call gates.
|
| | | | "... Já agora, "userland" é ring 2 ou 3 ..."
Userland é SEMPRE CPL 3 (o CPL 2, 1 e 0 são super-user) e devem ser usados em system-space (system calls), driver-space (drivers) e kernel-space (kernel base) respectivamente. O CPL 3 é o único que não tem acesso a super-user pages (usadas no kernel-space).
"... mecanismo de protecção ia-32 é uma salsada completa e não resolve todos os problemas ..."
O MMU do IA-32 é perfeitamente seguro se for correctamente utilizado (os segmentos controlam os privilégios de execução, as páginas controlam os privilégios de acesso). Num multi-segmented system (onde se usa uma LDT por processo sobre endereços vrituais paginados) tens 100% de segurança, podes definir exactamente em que pages queres dar read, write, execute e protect privileges usando a segmentação.
"... Que eu me lembre alguns sistemas operativos continuam a usar stacks mapeadas em descriptors com permissão de execução e áreas de dados com a mesma política. ..."
Infelizmente o MMU da IA-32 não funciona da mesma forma que os outros pois não é possível controlar os execute privileges directamente nas pages se não for usada a segmentação (que não é muito portável), nestes sistemas não só a stack mas mesmo os mapas onde não há execute privileges (como a heap) são executáveis pois tanto o code como o data segment cobrem os 4GB virtuais. O MMU da IA-32 é perfeitamente seguro se for utilizado como deve ser.
"... Outros exemplos comuns são implementações deficientes ou "trapalhonas" de serviços baseados em call gates. ..."
As call-gates são mais usadas do que imaginas. Um interrupt é uma call-gate (e tu usas um cada vez que chamas uma system call), eles são bastante efectivos e seguros.
Mais informações aqui.
Do you know the difference between education and experience? Education is when you read the fine print; experience is what you get when you don't. |
| | | | Userland é SEMPRE CPL 3 (o CPL 2, 1 e 0 são super-user) e devem ser usados em system-space (system calls), driver-space (drivers) e kernel-space (kernel base) respectivamente. Devias ter lido os manuais do teu link. Estás a confundir a hierarquia do modelo de protecção com a hierarquia de segurança em unix. O conceito de super-user nada tem que ver com o modelo de protecção em hardware. Já agora, relê os manuais e vê lá que nível de previlégio precisas para utilizar a LDT... Não sei se sabes mas em BSD existe uma flag de USER_LDT (acho que vem activa por defeito em linux) para os programas de userland poderem alocar descriptors na LDT. Outro caso curioso é eventual código (drivers, etc) que corra em v86... qual é o PL? (Sim, o linux tem funções in-kernel para gerir mode-switch para v86) O CPL 3 é o único que não tem acesso a super-user pages (usadas no kernel-space). As mudanças de previlégio para níveis superiores _só_ pode ser feita através de gates e/ou task switch. Isto é válido do nível 2 para o nivel 1, ou do nível 1 para o nível 0. Existem casos especiais, que são os segmentos de código "conforming" que podem ser executados com um CPL Infelizmente o MMU da IA-32 não funciona da mesma forma que os outros pois não é possível controlar os execute privileges directamente nas pages se não for usada a segmentação (que não é muito portável), nestes sistemas não só a stack mas mesmo os mapas onde não há execute privileges (como a heap) são executáveis pois tanto o code como o data segment cobrem os 4GB virtuais. O MMU da IA-32 é perfeitamente seguro se for utilizado como deve ser. Uma vez mais, se leste os manuais e percebes o mínimo de formatos binários baseados em COFF, por cada binário deveria haver pelo menos 3 descriptors que não são sobrepostos: O de stack, o de código e o de dados. Os formatos baseados em COFF (como o ELF ou o Win32 PE) têm uma tabela de relocação de offsets de objectos de dados, precisamente para esse efeito. As call-gates são mais usadas do que imaginas. Um interrupt é uma call-gate (e tu usas um cada vez que chamas uma system call), eles são bastante efectivos e seguros. Não precisas de ir muito longe para encontrares uma implementação "trapalhona" de uma call gate. Basta leres os manuais da intel e reparares no pormenor de o linux usar passagem de parâmetros por registo na int80h, em contraste com os outros unixes e derivados. Para terminar, um sistema baseado no mecanismo de protecção IA-32 que o use em toda a sua extensão é forçosamente limitado. A GDT tem um limite de 64Kb, ou seja 8191 entradas (a primeira tem que estar a zeros). Cada Task Segment, IDT segment, e LDT segment têm que ter um descriptor válido na GDT. Assim à partida e com muita sorte terias 8180 tarefas no máximo, cada uma com pelo menos 64 bytes no TSS. Isso dá 512Kb só para os TSS. Agradeço qualquer correcção e/ou ponto de vista divergente do meu.
|
| | | | Erm... Desculpem o aspecto... Devia ter feito o preview... :P
|
| | | | 1 - O termo "super-user" vem do manual da intel, eu disse (caso não tenhas lido) que as super-user pages são usadas no kernel-space.
2 - És obrigado a usar uma LDT pois usas pagination e tens de ter pelo menos um CS e um DS definidos por task (que podem ser os mesmos em todas as tasks e pode ser aplicada aqui a técnica de copy-on-write para poupar memória). Se queres confirmar isto, pegas num debugger qualquer e verificas os valores do teu CS e DS, vais ver que nenhum deles aponta para a GDT.
3 - Em Linux podes utilizar a modify_ldt() que é uma system-call (logo uma call-gate para o kernel-space (CPL0)) para alterar a LDT do teu processo. Isto pode ser utilizado por aplicações no user-space (CPL3) para configurar alguma protecção em conjunto com os privilégios da mmap (que definem os read-only/write privileges das pages, mas não os execute privileges porque a IA-32 não tem essa capacidade ao nível da pagination) e da mprotect() (que torna as pages acessíveis (ou não) apenas ao kernel-space (CPL2, 1 e 0)) embora isto seja apenas um hack no user-space e como tal não recomendado por razões de portabilidade do código.
4 - Correr drivers em virtual mode? E como é que fazes MMIO com esses drivers? Ou só vais usar PIO e DMA (e consequentemente esquecer PCI/AGP)? O virtual mode serve para permitir a execução aplicações escritas para 8086 nativo em modo protegido, não drivers de 32 bits.
5 - Não entendi onde raio é que isto se encaixa como resposta ao meu comentário: "... As mudanças de previlégio para níveis superiores _só_ pode ser feita através de gates e/ou task switch. Isto é válido do nível 2 para o nivel 1, ou do nível 1 para o nível 0. Existem casos especiais, que são os segmentos de código "conforming" que podem ser executados com um CPL ...", talvez estejas nervoso (e como tal até te esqueceste de formatar correctamente o texto (é compreensível)).
6 - Provavelmente quem não entendeu lá muito bem as specs descritas no manual foste tu. Existe um problema com a implementação dos mapas de memória em conjunto com a segmentação: é que os segmentos não têm uma base aleatória; se definires um segmento com base em 0xA0000000 o endereço 0x1 dentro desse segmento vai ser traduzido para 0xA0000001 antes de ser passado pelo hardware da pagination e ser traduzido para um endereço linear físico, logo tens de ter overlapping code e data segments para conseguires usar os mapas de memória virtual da mesma forma que usas noutros MMUs. Mais uma vez, se pegares num debugger em Linux e vires os valores do teu CS, DS e SS (que incrívelmente é igual ao DS e consequentemente deita por terra o teu argumento de que os segmentos não podem overlappar) e depois usares a modify_ldt() para verificar onde começam e acabam ambos os segmentos vais ver que ambos mapeiam os 4GB de memória virtual.
7 - Consegues correr mais de 1024 processos num i386 (mesmo com SMP) e mante-lo com uma performance aceitável? Good luck. Ah, e já viste alguma aplicação alocar mais de 128 mapas de memória em simultâneo? Não, pois não? Então o que te faz pensar que alocariam 8192 segmentos na LDT?
Os teus nervos deram muito nas vistas no teu último post (tanto que até te esqueceste da formatação, tal não foi a aflição de escrever algo para tentar contradizer-me).
Para quem possa eventualmente ter ficado confundido com o term "super-user pages" eu explico: este é o termo utilizado pela Intel nos manuais da IA-32 para descrever pages às quais uma aplicação no user-space (CPL3) não tem acesso, este termo não tem nada a ver com o super-user do sistema operativo (que corre no user-space (CPL3) com os mesmos privilégios sobre o processor que todos os outros).
Do you know the difference between education and experience? Education is when you read the fine print; experience is what you get when you don't. |
| | | | | Antes de mais, agradeço-lhe ter lido o que escrevi e agradeço também a sua entusiástica resposta. Passo então a clarificar os pontos que indicou: 1 - Agradecia que precisasse exactamente onde viu o termo "super-user", visto que uma busca de texto aos pdf's que indicou não devolve nada, e uma revisão pela cópia impressa que a intel distribui também não revelou nada. Se estiver em versões anteriores dos livros, avise, visto que tenho as diferentes revisões dos 3 manuais desde 1997. Será que é um bug no text search do acrobat reader, ou falta de jeito da minha parte? 2 - Não percebeu bem o que escrevi sobre segmentação. Ninguém disse que não era preciso usar uma ldt. O que disse, e mantenho, é que CS:offset deveria ser diferente de DS:offset, ou seja, deviam mapear zonas de memória diferentes.Os formatos binários de uso corrente prevêem essa situação, mas não é usada na prática. É assim que, por exemplo, um cs:esp e um ss:esp correspondem ao mesmo endereço linear. Curiosamente até existe um tipo de descriptor para ser usado em stacks (data descriptor, expand-down). Numa correcta implementação usando IA-32, teria pelo menos 3 descriptors por task e não 2, como indicou. 3 - Se quisermos ser estritamente correctos (e seguindo o manual da Intel), um syscall no linux não é um call gate, mas sim um interrupt gate. Talvez não tenha compreendido o funcionamento de um call gate e o mecanismo de cópia de stack que o cpu disponibiliza para as call gates (daí eu ter mencionado as implementações "trapalhonas"). Também tem a sua piada o facto de eu ter dito que o userland é ring 2 ou 3, dependendo da implementação. Ou seja, nunca disse que a userland era exclusivamente em ring 2 ou em ring 3, e até lhe explico porquê: porque conheço duas ou três implementações em cujo userland é ring3, mas não há nada que impeça a concepção de um sistema com userland em ring2... ou há? Quanto a protecção de execução per-page, penso que não deve ter percebido o que expliquei. Se usar descriptors separados para codigo, dados e stack (que não estejam sobrepostos), tem na mesma controlo da execução (só pode executar código no segmento indicado pelo descriptor apontado por CS, esteja este na GDT ou na LDT). Alguns SO's disponibilizam segmentos de stack randomizados precisamente para evitar o que indiquei no ponto anterior, e anunciam-nos como "features". Outra vez má implementação, ou então eu percebi mal o manual, também é provável. 4 - Ainda bem que me explicou o funcionamento do vm86, porque eu realmente não o tinha percebido até hoje. Poder-me-á fazer o obséquio de explicar a utilidade da reflexão de IRQ's para v86 disponível no ficheiro arch/i386/kernel/vm86.c do source do kernel do linux 2.6 e o syscall vm86. Já agora gostava também que me explicasse exactamente como funciona o suporte vesa em versões anteriores à 3.0, e a enumeração de devices nas bios PnP antigas, visto que me afirma que usar vm86 em drivers é invocar o anticristo. 5 - A esta altura do campeonato, é óbvio que ainda não percebeu. Se lesse os manuais, encontrava lá isso. Dou-lhe uma pista: o contexto eram as gates. E espero que esta formatação esteja mais do seu agrado, não quero que se sinta confuso com as minhas explicações. De acrescentar que de "presunção e água benta, cada um toma a que quer". Mas não vá por mim, os grandes egos sempre se alimentaram da pior das ignorâncias: a presunção. 7 - Não, não vi porque as minhas necessidades nem o impõe. De qualquer forma o que eu disse foi que segundo a implementação documentada no manual da intel, cada TSS tem um descriptor na GDT e que cada LDT tem um descriptor na GDT, e eventualmente cada task tem a sua própria LDT. Não sabe ler? Deve ter sido a formatação que o confundiu, peço desculpa pelo aspecto pouco claro. Já agora, o que para si um "mapa de memória"? Outra expressão copiada dos livros da intel? Que posso dizer mais? A arrogância de trazer por casa e o discurso de café têm um efeito nefasto nos meus nervos, fazem-me clicar no "submeter" sem fazer a pré-visualização online. Já agora, qualquer pessoa minimamente atenta percebia que me enganei. O "super-user" até tem acesso aos segmentos do kernel em ring0 em unix... Esqueci-me do /dev/mem e do /dev/kmem. Claro que isso também lhe passou ao lado. Deve ter sido a formatação que bloqueou o raciocínio. Ahh e se estiver interessado, talvez lhe possa indicar um bom psicólogo para tentar resolver essa coisa do ter a mania que as pessoas lhe dão tanta importância que o tentam apanhar em contradição. Já me foi recomendado por eu estar sempre a responder a putos que têm a mania. Enfim, uma destas perturbações mentais modernas provocadas pela internet... Sobre a tua epígrafe... O que é um "pointer" e porque é que (aparentemente) só existe em C?
|
| | | | 1 - Se fosses minimamente inteligente tinhas procurado por "super" e encontrado algo parecido com isto: "... User/supervisor (U/S) flag, bit 2 Specifies the user-supervisor privileges for a page or group of pages (in the case of a page-directory entry that points to a page table). When this flag is clear, the page is assigned the supervisor privilege level; when the flag is set, the page is assigned the user privilege level. This flag interacts with the R/W flag and the WP flag in register CR0. See Section 4.11., "Page-Level Protection", and Table 4-2 for a detail discussion of the use of these flags. ..." (pp90). Concordo que aqui foi misspell minha, mas a ideia generalizada de super-user e supervisor não difere muito (pelo menos na minha opinião).
2 - Estamos a falar do que existe, não do que deveria existir, se fossemos discutir o que deveria existir, então os sistemas deveriam ser todos alterados e os mapas de memória actuais substituídos por segment descriptors (e aí sim o MMU da IA-32 funcionaria a 100% e sem qualquer problema de segurança (como disse antes)).
3 - A userland nunca é CPL2, CPL2 tem supervisor access à memória da maquina e seria uma má utilização do MMU (ainda pior que a do linux) porque deixaria de ser possível (pelo menos de forma linear) tornar áreas de memória inacessíveis ao processo e para alem disso se formos por esse ponto de vista, também não há qualquer problema em ter a userland no CPL1. Não dês maus exemplos para te justificar, ainda por cima exemplos que vão directamente contra as especificações da Intel. A minha intervenção deve-se ao facto de teres dito que o MMU da IA-32 ser uma salganhada e não ter suporte para certas coisas (o que não é de todo verdade). Agradeço que não fujas do tópico e que não repitas o que eu já disse antes. Volto a repetir o que disse: o MMU da IA-32 é perfeitamente seguro se for usado devidamente (o que não acontece nem em Windows, nem em Linux nem em BSD).
4 - MMIO não fazes em virtual mode por mais que te estiques, não preciso de explicar sources do kernel (que neste momento não estou com paciencia para ler sequer). Podes continuar a usar PIOs, IRQs e DMAs (visto que o DMA controller funciona por PIO), mas não podes usar MMIO porque o MMIO só está disponível em protected mode, como tal, não há PCI (e consequentemente AGP) para ninguem. Gostava de ver alguem contrlar um MMIO com uma abertura de 256MB em virtual mode. :-)
5 - O que eu não entendi foi onde é que o que escreveste se enquadrava naquilo que eu disse porque apareceu do nada e já agora também é posssivel usar gates do CPL3 para o 2, 1 e 0. Cá vai mais uma quote do manual: "... Interrupt and trap gates are very similar to call gates (see Section 4.8.3., "Call Gates"). They contain a far pointer (segment selector and offset) that the processor uses to transfer program execution to a handler procedure in an exception- or interrupt-handler code segment. These gates differ in the way the processor handles the IF flag in the EFLAGS register (see Section 5.12.1.2., "Flag Usage By Exception- or Interrupt-Handler Procedure"). ..." (pp153) na prática eles são MESMO usados como call-gates, a única diferença é que são chamadas por ints e não por calls.
6 - Gostava de saber porque é que saltaste este ponto... Será dos nervos novamente? ;-)
7 - Só três comandos: "cat /proc/self/maps" (em linux), ficas iluminado quanto aos "mapas de memória", "man 2 mmap" e "man mprotect".
8 ? - O super-user (do OS) não tem privilégio no processador para aceder directamente a essas áreas de memória, o acesso que tem é por um wrapper e que eu saiba estamos a falar de privilégios concedidos pelo MMU, não pelo kernel. Vendo as coisas por esse prisma até um user normal com CAP_DAC_OVERRIDE (ou com privilégio para aceder ao inode) tem acesso a essa memória. É incrivel como começas a ver se alguma das postas de pescada cai no cesto... Falta de argumentos?
9 ? - Escusas de me tratar por você.
10 - Já a gora, e para terminar, gostava que me explicasses o que queres dizer com isto (é que ao fim ao cabo ficamos todos sem saber quais são os problemas que o MMU da IA-32 não resolve): "... De qualquer forma, é do senso comum que o mecanismo de protecção ia-32 é uma salsada completa e não resolve todos os problemas. ..."
Do you know the difference between education and experience? Education is when you read the fine print; experience is what you get when you don't. |
| | | | Bem, leva lá a bicicleta... (está bem formatado?)
|
| | | | e q tal amansarem a franga com algo mais educativo em vez de tarem a ler as specs da intel, que ao contrario de outras coisas boas, so fazem mal a' nerva?
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| | | | FreeBSD conseguiu estar á frente dos ditos free OSs.
Onde ? Como ? Falas do que ? Não digo que por default não possa passar muitos, agora também te digo que quem tiver olhos na cara e saiba usar uma coisa named "RSBAC" + "Linux kernel" descobre um mundo completamente diferente de segurança e largamente superior ao vosso freebsd default world.
Nao sou contra patchar o kernel pra teres isto ou aquilo. Usar algo mais ortodoxo ou mesmo RBSAC.Para quem tem tempo e espera retorno do investimento aka $$$, deve perder o minimo que seja pra criar algo seguro mas ao mesmo tempo q seja facil de manter e sobretudo que se sinta confortavel com.
Aquele ditado de matar uma bazuca com uma mosca podiase aplicar aqui, mas nao, a diferenca ta em algo tao simples como man jail ou make installworld DESTDIR=/usr/jail qd sai um SA e ou e' necessario actualizar a base system. E isto tudo outofda box. Fantatische mike!
Tu dentro de uma jail podes ter algo tao simples como, apenas o processo que queres disponibilizar e ao contrario do que foi aqui dito nao precissas de definir um ip por cada jail, desde q tenhas o servico a correr em portas diferentes, tjeres no harm done
Um servidor de teamspeak, enemyterritory, CS etc, ftp e um httpd para pagina do clan a quem vendes como se de uma box se tratasse. Ou um apachezito com mysql/php, ftp e ssh pro site comercial.
E' algo tao simples, que meto um servidor icecast a bombar em 3 tempos dentro de uma jail. Ou numa lan com 100 manfias, nunca se sabe o que se pode encontrar, proftd ou pure jailed e ta a andar
Quem diz isso, fala em espetar o qmail ou o bind a responder a requests exteriores do mesmo modo. Rootou a maquina, nao faz mal, ta na jail nao sai.
E' como cerrar as grades e entrar pela janela de uma cela. Entraste no castelo, mas tas dentro de uma cela. Now what? a tua frente ta uma porta de ferro? Trouxeste o macarico?
btw greenmile muito bom moves :'(
Mas a ideia e' essa, na jail partes do nada e so la metes o que raio bem queres(e ou removes o que nao interessa). Nao precissas de andar a definir tudo a priori, o que pode o que nao pode fazer. Pra nao falar de confs de chroots. Jails com securlevels e um bom login.conf e nao queres mai nada.
MACs, o freebsd desde a 5.x ja vem com supporte macs. Ta a fazer catch up das specs, com a implementacao da framework do trustedbsd. E' so esperar pela 5-stable, pra se ver algo mais especifico nesta area. Q por este andar so la vem pra finais de maio/junho qd sair a 5.3.. :(
Pro PLS, um bom artigo de opiniao, nem que tenha servido pelo alerta de qua existe algo que pelos vistos muitos desconhecem, mas que e' facil de implementar e sobretudo de manter.
Performance e espaço em disco.
Obviamente que há um impacto em ter “várias userlands” (o kernel é comum a todas as “jails”), cada uma com os seus “daemons” próprios (apache, mysql, etc) a correr. Mas o impacto é bastante menor que utilizar “máquinas virtuais” (usermode Linux, vmware e afins).
make package, ou pkg_create -b fazem maravilhas ;)
E agora um bom resto de dia de natal para todos,
que eu tenho coisas mais importantes para fazer :D
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| | | | Sim, dou-te razão nesse aspecto, alias nunca neguei que o "aproach" das patches de security fosse algo que exige maiores percas de tempo por parte do administrador, ou que a maneira que o pls implementou para resolver o problema em questão fosse a mais indicada para o produto final pretendido. O meu ponto aqui foi apenas demonstrar que tens vários caminhos para chegar a roma, e que o linux kernel é algo que sempre viveu, e que sempre viverá também das patches não oficiais, ao contrario dos BSD onde a oferta exterior à oficial é sempre muito limitada.
A rsbac é uma excelente patch, e na minha opinião quanto a níveis de segurança (que alias foram falados neste tópico) permite que o linux kernel ultrapasse largamente qualquer BSD que eu conheço (sim openbsd incluindo).
Claro que isto são opiniões pessoais minhas, mas incentivo a todos vocês que exprimentem a patch, e que depois mandem umas opiniões.
|
| | | | | | | | Claro q, seguindo um comentario anterior... Seria excelente se houvesse algo para transformar um x86 numa espécie de "Poor Man's zSeries". ... também se pode sempre recomendar o total overkill: é instalar o Hercules, um emulador dos Z Series Mainframes da IBM, e por-lhe a correr o Linux for S/390 (Linux for Big Iron), com todas as vantagens q daí advêm. Isto sem falar em ter a possibilidade de aprender MVS, S/390, VM/ESA ou z/VM e passar a ter alguma coisa para fazer nesta semana em alternativa a coçar os tomates :-). Também apresenta enormes vantagens para a) ignorar a namorada/mulher ou b) ganhar um divorcio :-) Mais a sério: a performance não é fantástica, mas na minha Dell (ou em qq maquina multiprocessador) tem uma performance superior aos originais P/390 e R/390 da IBM. E já houve tipos que conseguiram por mainframes IBM390 *reais* com 41400 Linuxes virtuais (em testes) e com 3200 (em produção). Cumprimentos Mario Valente
|
| | | | O FreeVSD e o FreeVPS parecem-me soluções (patches) demasiado ligadas ao redhat 6 -> 7.3, e respectivo layout/userland. Esta abordagem tem todo o potencial para se transformar num pesadelo de manutenção em pouco tempo. Já o Linux VServer me parece oferecer uma abordagem mais flexivel e abrangente e entre as 3 hipoteses ser a que eu seguiria (se fosse montar/manter algo deste tipo em linux... o que pode vir a acontecer se utilizar linux for um obrigatório no projecto). Bom era que fosse integrado e mantido de origem em distribuições de linux, à semelhança das jails do FeeBSD. Talvez no Caixa Mágica consiga convencer o Paulo Trezentos que isto é uma boa ideia. :-) PLS
|
| |
|
