O kernel do FreeBSD está 'bloqueado'?

0

Por acaso, conversei com um Mac Genius sobre vírus.

Ele mencionou que o kernel do FreeBSD no qual o Mac OS é baseado é 'bloqueado' e, portanto, nenhum vírus pode prejudicar o meu Mac.

Eu não entendi muito bem o que ele queria dizer.

Alguém poderia explicar?

    
por Enthusiast 31.01.2011 / 16:38

2 respostas

10

Ele não sabia do que estava falando. Há algumas coisas que eu posso pensar que ele está falando:

  1. O usuário efetua login como não-superusuário, de modo que os processos do usuário não podem simplesmente carregar módulos ou fazer alterações no kernel de outras maneiras. (claro, qualquer vírus macosx iria explorar falhas no kernel para contornar isso, ou apenas usar engenharia social para fazer o usuário digitar a senha)
  2. O MacOSX tem melhor proteção de memória que versões anteriores a 10.0. Talvez o "gênio" esteja se lembrando dos dias com MacOS 9 e anterior? Quase todos os sistemas operacionais modernos têm isso agora e não impediram os criadores de vírus.

Eu acho que esse Mac Genius provavelmente estava apenas se lembrando de algum marketing. MacOSX pode pegar vírus. Existem certamente algumas vantagens em usar um sistema similar ao Unix, e talvez o microkernel Userland + Mach do BSD também forneça alguma proteção adicional, mas é demonstrativamente falso dizer que o kernel MacOSX é de alguma forma protegido contra vírus.

    
por 31.01.2011 / 16:52
2

Ele pode estar se referindo à variável kern.securelevel do freebsd, que parece existir no osx 10.8, presumivelmente com o mesmo significado. De fbsd man 7 security:

 The security level can be set with a
 sysctl(8) on the kern.securelevel variable.  Once you have set the secu-
 rity level to 1, write access to raw devices will be denied and special
 chflags(1) flags, such as schg, will be enforced.  You must also ensure
 that the schg flag is set on critical startup binaries, directories, and
 script files -- everything that gets run up to the point where the secu-
 rity level is set.  This might be overdoing it, and upgrading the system
 is much more difficult when you operate at a higher security level.  You
 may compromise and run the system at a higher security level but not set
 the schg flag for every system file and directory under the sun.  Another
 possibility is to simply mount / and /usr read-only.  It should be noted
 that being too draconian in what you attempt to protect may prevent the
 all-important detection of an intrusion.

 The kernel runs with five different security levels.  Any super-user
 process can raise the level, but no process can lower it.  The security
 levels are:

 -1    Permanently insecure mode - always run the system in insecure mode.
       This is the default initial value.

 0     Insecure mode - immutable and append-only flags may be turned off.
       All devices may be read or written subject to their permissions.

 1     Secure mode - the system immutable and system append-only flags may
       not be turned off; disks for mounted file systems, /dev/mem and
       /dev/kmem may not be opened for writing; /dev/io (if your platform
       has it) may not be opened at all; kernel modules (see kld(4)) may
       not be loaded or unloaded.

 2     Highly secure mode - same as secure mode, plus disks may not be
       opened for writing (except by mount(2)) whether mounted or not.
       This level precludes tampering with file systems by unmounting
       them, but also inhibits running newfs(8) while the system is multi-
       user.

       In addition, kernel time changes are restricted to less than or
       equal to one second.  Attempts to change the time by more than this
       will log the message ''Time adjustment clamped to +1 second''.

 3     Network secure mode - same as highly secure mode, plus IP packet
       filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be
       changed and dummynet(4) or pf(4) configuration cannot be adjusted.

 The security level can be configured with variables documented in
 rc.conf(8).

Os sinalizadores imutáveis e anexados podem ser definidos em dirs ou arquivos usando o comando chflags. Para diminuir ou desativar o nível de segurança do kernel, você precisa inicializar um único usuário. Advertência: Não sei se o osx faz uso total desse recurso, só sei que está disponível.

Advertência 2: o osx é baseado no kernel mach. O material da userland é do freebsd. Ainda assim, vejo que o kernel tem essa variável definida, então estou pensando que isso pode significar a mesma coisa.

    
por 14.11.2012 / 23:44