Deem uma lida nisso.
----
LinSec team is proud to announce the first stable release of LinSec.
LinSec, as the name says, is Linux Security Protection System. The main
aim of LinSec is to introduce Mandatory Access Control (MAC) mechanism
into Linux (as opposed to existing Discretionary Access Control
mechanism). LinSec model is based on:
* Capabilities
* Filesystem Access Domains
* IP Labeling Lists
* Socket Access Control
As for Capabilities, LinSec heavily extends the Linux native capability
model to allow fine grained delegation of individual capabilities to
both users and programs on the system. No more allmighty root!
Filesystem Access Domain subsystem allows restriction of accessible
filesystem parts for both individual users and programs. Now you can
restrict user activities to only its home, mailbox etc. Filesystem
Access Domains works on device, dir and individual file granularity.
IP Labeling lists enable restriction on allowed network connections on
per program basis. From now on, you may configure your policy so that no
one except your favorite MTA can connect to remote port 25
Socket Access Control model enables fine grained socket access control
by associating, with each socket, a set of capabilities required for a
local process to connect to the socket.
LinSec consists of two parts: kernel patch (currently for 2.4.18) and
userspace tools.
Detailed documentation, download & mailing list information -
http://www.linsec.org
-----Original Message-----
From: Thiago Madeira de Lima [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 11, 2002 3:46 PM
To: 'Lisias Toledo'; 'Thiago Pimentel'
Cc: 'Depto de Tecnologia - H�fig'; 'Linux-br'
Subject: RE: (linux-br) Virus no linux
Meus 2 centavos.... :)
E' tarefa da kernel bloquear acesso a funcoes, filesystems e
devices de acordo com as permissoes do usuario. Pra que um virus se
prolifere no sistema inteiro ele tem que ter acesso ao sistema todo,
como root.
Se a kernel bloqueia direitinho o acesso de um usuario/grupo o
virus nao consegue se proliferar, nao consegue acessar a memoria ou os
arquivos utilizados por outros programas, a nao ser que todos os
programas sejam rodados pelo mesmo usuario. Sem esse acesso o virus
ficaria limitado ao userspace do usuario que rodou o virus. Se nao foi o
root que rodou o sistema continuara limpo, somente os arquivos do
usuario em questao estao contaminados. Se a kernel nao bloqueia tais
chamada e' pq ela esta com algum bug e isso tem que ser corrigido.
Agora se o usuario consegue executar tarefas que prejudiquem o
sistema (ex: estourando processos, memoria ou utilizando toda a cpu) ,
e' tarefa da kernel impedir isso, colocando novos niveis de controle por
processo/usuario. O linux nao implementa todos os tipos de 'travas'
possiveis contra um systemcrash como por exemplo o solaris implementa.
(esse e' um dos motivos dele ser mais rapido que o solaris).
Thiago Madeira de Lima.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Lisias Toledo
Sent: Friday, October 11, 2002 1:07 AM
To: Thiago Pimentel
Cc: Depto de Tecnologia - H�fig; Linux-br
Subject: Re: (linux-br) Virus no linux
Thiago Pimentel wrote:
>
> 8/10/2002 05:38:38, Lisias Toledo <[EMAIL PROTECTED]>
> wrote:
> > [...] � TAREFA DO KERNEL evitar que aplica��es
> > userland de um
> > usu�rio interfira com as de outro ou no sistema.
> N�O � FUN��O DO KERNEL bloquear acesso a fun��es de uso esperado por
> uma aplica��o! O kernel n�o tem condi��es de descobrir se uma
> aplica��o � maliciosa ou n�o[...] logo � ESTUPIDEZ dizer que o kernel
> Linux tem alguma coisa inerente a ele que impe�a a prolifera��o de
> v�rus, pq ISSO NAO EXISTE.
A partir deste ponto, a dicuss�o entrar� em loop. Eu repetirei os mesmos
argumentos e vc replicar� igualmente.
Minha posi��o � que v�rus se proliferam interferindo nas demais
aplica��es e no sistema, atrav�s de chamadas ao sistema que estejam
liberadas ou explorando um filesystem (parcialmente ou totalmente)
aberto.
Acho que podemos resumir nosso pega-pra-capar em :
1) Vc afirma que tudo isto � uso esperado de aplica��es userland. Vc
est� irredut�vel.
2) Eu afirmo que � tarefa do kernel evitar que isto aconte�a. Eu estou
irredut�vel.
Como nenhum de n�s dois vai voltar atr�s, sugiro passar o bast�o e
deixar a discuss�o rolar com outras pessoas (talvez at� em outras
listas).
--
[]s,
([EMAIL PROTECTED]
niverse)
Bose-Einstein Condensation : A new concept on Software Development.
Assinantes em 16/10/2002: 2233
Mensagens recebidas desde 07/01/1999: 186929
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
