0

I happened to talk to a Mac Genius on the subject of viruses.

He mentioned that the FreeBSD kernel on which the Mac OS is based is 'locked' and therefore no viruses can ever harm my Mac.

I didn't quite understand what he meant.

Could someone explain?

Naweed Chougle
  • 101
  • Related: http://unix.stackexchange.com/questions/2751/the-myths-about-viruses-in-unix-linux – wag Jan 31 '11 at 15:59

2 Answers2

9

He didn't know what he was talking about. There are a couple things I can think that he's talking about:

  1. The user logs in as a non-superuser, so user processes can't simply load modules or make changes to the kernel in other ways. (of course, any macosx viruses would exploit flaws in the kernel to bypass that, or just use social engineering to get the user to type in the password)
  2. MacOSX has better memory protection than versions earlier than 10.0. Perhaps the "genius" is remembering the days with MacOS 9 and previous? Nearly every modern OS has that now, and it hasn't stopped virus writers.

I think this Mac Genius probably was just mis-remembering some marketing. MacOSX can get viruses. There are certainly some advantages to using a Unix-like system, and perhaps the BSD Userland + Mach microkernel does also provide some added protection, but it is demonstratively false to say that the MacOSX kernel is somehow protected from viruses.

jsbillings
  • 24,406
  • Just thinking out loud here but if the boot-loader checks the checksum of the kernel against it's own database before loading it, that would protect the kernel from a certain class of viruses. However, I'm not sure if OSX does this. – sybreon Feb 02 '11 at 04:39
2

He may have been referring to freebsd's kern.securelevel variable, which seems to exist in osx 10.8, presumably having the same meaning. From 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).

The immutable and append flags can be set on dirs or files using the chflags command. In order to lower or turn off the kernel securelevel you need to boot single user. Caveat: I don't know if osx makes full use of this feature, I only know that it's available.

Caveat 2: osx is actually based on the mach kernel. The userland stuff is from freebsd. Still, I see the kernel has this variable defined, so I'm thinking it might mean the same thing.

rich
  • 21