Re: New Patch Fixes 43 Flaws In OS X, Many Serious

"sav" <notthisbitsavage@xxxxxxxxxxxxxxxxx> wrote in message
news:e4d72m$1rf$1@xxxxxxxxxxxxxxxxxxxxxxxxx
I have seen that answer before on this newsgroup, and I think
it means that you have no idea what you are talking about; you
are trying to conceal this fact by referencing a book which you
are confident I won't read. I am then supposed to conclude
that it somehow supports you.

He said, "the answer is too long to post". I found a shorter answer,
that is not so thorough, but I suspect by your ignoring of previous
explanations this one won't do for you either.

Out of respect for your.. concerns about being
ignored, I will reply and not snip any content this time.

But this article *is* irrelevant; it deserves to be
ignored. It does not advance any argument about
Mac OS X having any sort of 'inherent resistance'
to malware.

It is also very, very elementary. It is actually a rather
cursory high level summary of some of the features of
Mac OS X.

That you should post this strikes me as a tactic; you
assumed I would not read it, or respond to it, simply
because it is very long (for Usenet). I guess that,
had I ignored it, you would then point at it as
'unanswerable proof'.

I will therefore address it; but kindly do nothing of
the sort again. It's a waste of time.

Out of the box, root is disabled. It doesn't seem to mention that here,
and if I go on to to other things this will become too long. it would be
easy enough for you to find out this yourself, but from your attitude it
doesn't look like you really want to know, just to put down what others
here are saying.

Note that out of the box, root is functional; it is not available
as a conventional login but you can obtian a root shell using
sudo, and in various other ways.

Some people get confused about this, and think that since
root is "disabled", it is gone and can't be abused. This is
not so.

anyway, here it is:

A Quick Primer in UNIX/BSD

Mac OS X is new, but it has a long family history. It is a descendent of
the BSD UNIX family and the original AT&T UNIX, which have been around
more than 30 years.

This isn't true; Mac OS X is very clearly a NeXTStep derivative;
it's kernel is Mach, it's userspace is built on AppKit.

They retrofitted some BSD code in there and got pretty good
Unix-compatibility thereby; but it's no more a descendant
of BSD than Windows NT was when it had the BSD network
stack in it. And of course it's not a descendant of the original
AT&T Unix either.

This history provides Mac OS X with excellent power
and stability, as well as a great deal more flexibility than earlier
versions of Mac OS. This is especially true if you?re willing to take a
look under the hood and work with the BSD subsystem directly.

I do not know what "power" is meant here, but features like
memory protection are being provided by Mach.

As you start working with the UNIX system, you should be familiar with a
few key concepts. These include:

* The multi-user nature of UNIX systems.
* The UNIX file system and associated permissions model.
* The way UNIX provides network services.

Onward, then!

UNIX?s Multi-user Nature

There are multiple user accounts in every UNIX system. Most of these
accounts are associated with actual, human users. For example, you
created an account when you supplied a username and password upon
installing Mac OS X. Every process and application is associated with a
user. So when you start an application after logging in, that
application will be associated with your username.

This is actually a mild oversimplifaction. A process may be assocated
with *two* users; that's what setuid does. A setuid process can
flip back and forth between the 'real' user and the false one setuid
provides.

This is important for security; it means that a setuid-root program
can, when desired, shed its rootness and have normal protections
enforced against it.

Of course, should such a program be subverted, it will certainly
be made to resume its 'root-ness' before trashing your system.

The Windows approach is better; it divides the program into
an unprivileged 'front end' and a privileged service; the front
end may be compromised, but it has no special ability
to become root, so this is harmless by itself.

UNIX systems also have accounts that are not associated with any person
logging into the system; rather, they are built into the system. Five
accounts are installed by default in Mac OS X: daemon, nobody, root,
unknown, and www. To understand the full significance of these accounts,
you?ll need to understand UNIX permissions, which will be discussed
shortly. For now, keep in mind that www is the account used by the
built-in web server, unknown and nobody provide minimal permissions, and
daemon runs system services that need some permissions.

This is all good.

The root account is very special ? it has no restrictions. Any
application or process running with the privileges of the root user can
read, write, or delete any file on the system; stop or start any
application on the system; or do anything else it pleases. There is
nothing the root user cannot do. Consequently, guarding access to the
root account is very, very important.

This is, of course, why root is a defect of the Unix model-
it is immune to security checks.

Apple knows this; that is why they prevent interactive log-on
as root.

In addition to users, UNIX has a concept of groups. A UNIX group is a
collection of individual accounts. In the UNIX file permission scheme,
which will be discussed shortly, you can grant permissions to a group.
This provides a way of allowing a selected set of users to have
identical access to files, directories, and applications, while denying
access to other users. Individual user accounts belong to a default
group and may be given membership in other groups.

This part is all good.

UNIX Filesystem and Associated Permissions Model

If you?ve worked with file sharing in previous versions of the Mac OS,
what you?ve read so far about users and groups should be familiar. Like
the older versions of Mac OS, each object in UNIX systems (a file or
folder) is owned by a user and is associated with a group. For each
object, specific permissions can be granted to the owner, to the group,
and to everyone else.

This very limit arrangement is a classic Unixism. This is
all rather inflexible.

There are three basic permissions: read, write, and execute. The
meanings of read and write are fairly straightforward; execute, however
has different meanings depending on whether the object is a file or a
directory. For a file, execute means the file is executable (that is,
it?s an application or a script), but if the object is a directory,
execute means that the class (owner, group, or everyone) has permission
to search the directory.

This is typical Unix-hackiness.

But Apple has been doing something about this; they now have
an ACL system. Not exposed in the Mac OS X client GUI, but
it's there all the same.

Because you can augment the filesystem with such a mechanism,
'permission bits' are not really as bad a fault as, say, root, or setuid.

You can view the permissions associated with any file by opening up the
Terminal application and using the ls command.

[snip- ls output]

The collection of letters and hyphens furthest to left indicates exactly
what each element is and the permissions for that element. The first
column of each line indicates the element?s type: d for directory, - for
a regular file, and l for a symbolic link, which is essentially the same
as an alias in Mac OS 9.x.

If I understand it properly, Apple still considers symbolic links too
fragile, and implements aliases with 'alias files', as in Mac OS 9.

This is probably wise.

The next three columns (rwx) show the
permissions for the owner, the next three for the group associated with
the file, and the last three for everyone. A - in any position indicates
a lack of that permission. For example, rw- indicates read and write
permissions, but no execute permission, and r-x indicates read and
execute permission, but no write access.

It's a somewhat limited selection of permissions, but
servicable. For a consumer OS, it will do.

For the third listing above (Apple/), you can look at the permissions
(drwxr-x ? -) and know that this is a directory (the first letter is d)
that has read, write, and execute permissions for the owner (rwx), read
and execute permissions for the group (r-x) and no permissions for
everyone ( ? -).

Though, of course, root still has access.

The owner (eric) and the group (users) are both shown here, as well as
the file size in bytes, the last modified date, and the filename. Also
shown are the current directory (symbolized by a single dot) and the
parent directory (symbolized by two dots).

Not to put too fine a point on it, but this is getting really
boring. This stuff is pretty much just a copy of the man page
for 'ls', and I find it astonishing that you saw it as relevant
at all.

Nevertheless, I do not excise it, since I do not want you
to think I ignored it.

UNIX Networking

UNIX systems are designed to be used in network environments.

This is not really so; that is, modern Unix is deployed in this way
but the original Unix was a time-sharing system. Very different.

It's come a long way since then, of course.

Frequently, UNIX systems host network services, such as Web servers,
file sharing, and database servers. Although there?s no need to run
these services on your Mac OS X box, you do have the option. You can
run, for example, the Apache Web server with PHP and Perl and the MySQL
database server in your development environment.

Must... resist... urge.. to... nap...

UNIX systems natively speak the various protocols of what is commonly
referred to as the TCP/IP suite. Each network service will be associated
with the IP address assigned to your machine. Additionally, each service
will be associated with a TCP or UDP port. Ports are a feature of TCP
and UDP that allow many processes on a single host access to TCP and UDP
services simultaneously. Ports are numeric in the range of 1 to 65535,
some of which are, by convention, assigned to specific services. For
example, the HTTP services is commonly assigned to TCP port 80. There
are a number of such assigned ports, but there are a far greater number
of unassigned ports ? that is, ports that are not commonly bound to a
service or application.

This is, of course, not so much a feature of Unix as of TCP/IP.

The combination of an IP address and a port makes a socket, and a pair
of sockets define a connection. Applications that provide network
services listen for connections on a socket. For example, a secure web
server commonly listens on the socket formed by the IP address of the
server and TCP port 443.

I may say this passage uses the term "connection" very losely;
a TCP connection is a much more complex sort of thing, and
UDP does not really have connections as such.

The more sockets that are active on your machine, the greater the
opportunity for an intruder to break into your box. More on this later.

This is unclear, but I know what he probably meant: computes that
expose a larger attack surface are more vulnerable, all else
being equal.

But it is a cardinal error to assume that the attack surface is
solely composed of sockings with daemons listening for
connections. He may be making that error.

Additional Reading

[snip- bibliography]

Mac OS X Security Out of the Box

Following the initial install, Mac OS X is fairly secure. A few simple
tweaks make it even more secure. But before we get to those changes,
there are a few things you should notice during the install process.

Such optimism! :D

Administrative Accounts

The first account created on a Mac OS X system is an administrative
account. If possible, this account should not be the account you
commonly use; it should be reserved for making changes to the system and
installing system-wide applications. After installing Mac OS X, go into
the Users item in System Preferences create a new account without
administrative access. For your common tasks, log in as that user.

Of course, Apple makes this first account the default. But Windows
can't throw stones here.

The root has been disabled, although it can be re-enabled if need be.
This means that all administrative tasks, such as turning on and off
various types of sharing and adding or deleting users, must be done by
one of the administrator accounts.

This is part of the reason why Apple does not make these
the default. This is, after all, a consumer OS.

The GUI tools for administrative tasks provide additional restrictions
in that they do not allow direct software installs or other edits to the
core portions of the OS. These restrictions prevent users from
accidentally breaking their systems. Any time you launch an
administrative tool, you will have to authenticate yourself by entering
the username and password of an administrative account to make changes.

Actually, sometimes the tools 'remember' that they were unlocked,
even across a relaunch. I believe this is a configuration setting.

Active Network Services

After the initial install, Mac OS X provides only a few network
services, automounter, syslog, sunrpc, and NetInfo, each of which will
be described in a moment. Having few network services available is a
good way to start off ? the fewer services available over the network,
the harder it is to break into your system. As an analogy, think of how
scaling a smooth wall is much harder than climbing one with good finger-
and foot-holds.

As I mentioned, this is an oversimplification.

The automounter service is used for automatically mounting network
volumes; syslog is both a process and a protocol for recording system
logs. The sunrpc service maps Remote Procedure Call (RPC) application
information into TCP/IP (a.k.a. Internet protocols). RPC is used for
services like Network File System (NFS) ? the standard method of file
sharing in UNIX. You can read more about sunrpc from this W3C
description and the RFC.

This is all pedestrian, but I should mention that NFS may be the
"standard" for file sharing in Unix, but it's a mess. It is, in particular,
highly insecure.

The NetInfo service is thoroughly described in Apple?s Knowledge Base.

And I am glad you didn't paste *that* in. :D

Other Network Services

A variety of other services are available for activation. File sharing
(AFP) over both TCP/IP and AppleTalk are available, as is Web sharing.
Starting up either of these services opens additional network services
and thereby introduces some risk; however, that doesn?t mean these
services are insecure.

AFP is surely more secure than NFS, anyway. :D

In-bound SSH and FTP services are also available in the Sharing System
Preferences panel but are best left turned off unless you have a
specific need for them to be active. SSH does provide for host-to-host
and individual account authentication. It does this while encrypting all
network traffic between the hosts. However, it is still an open service
that may provide an attacker leverage into your system.

This is misleading. FTP is a sort of file-sharing protocol; SSH
is a secure shell mechanism- it provides an encrypted channel
to access a shell. It does not, however, do "account authentication"
at all.

Simple Changes to Enhance the Security of Mac OS X

Note that as soon as you get here, this article you've pasted in
is arguing *against* the "inherent security" of Mac OS X; it's
pointing out the flaws.

Once Mac OS X is installed, three quick steps will enhance your
machine?s security:

* Create an additional, non-administrative account and use that for
all of your day-to-day work. Using a non-administrative account will
make it harder to damage your system because you won?t have the
privileges to commit a serious mistake.

Of course this is a repeat.

* Use the Mac OS X screen saver (Screen Effects). Not only is it
cool to look at, but it can also help protect your machine from others
who come by when you?re not around. Turn on the screen saver from within
System Preferences (it has its own panel) via the Activation tab ? 10 or
15 minutes for a startup time is a good default. Be sure to make the
screen saver ask for your password before releasing the machine.

This is not really much of a security measure; the protects your Mac
from people with *physcal access* to your Mac.

But if they can pick it up and walk off with it, then none of the
rest of this is going to matter much.

* Turn on Network Time Synchronization. This is a good idea,
particularly if you have a constant connection to either a local NTP
(Network Time Protocol) server or the Internet. Ask your local systems
or network administrator if you have a local NTP server. Keeping your
clock synchronized to official time is helpful in coordinating forensics
of an attack and detecting alterations to the system.

I do not see how this offers *any* security at all.

On-the-box Firewalling

You can minimize the risk of a network service being used to attack your
machine by using the firewall built into Mac OS X. Called ipfw, it can
prevent potential attackers from reaching these services. As of Mac OS X
10.2, Apple has included a simple GUI for configuring ipfw. The GUI is
good for adding simple rules to your machine; more complex rules will
require you to use either the command line tools for manipulating the
firewall, or a third-party GUI that has more features. Building a
comprehensive firewall requires a detailed understanding of what the
firewall rules do and a certain amount of skill. Understanding TCP/IP
networking is also important. Note that building firewall rulesets can
cause your network connection to stop working, so be sure to invoke
ruleset additions and changes directly on your machine and not from a
remote location.

Apple has made their fireware commendably easy to use, but
it is turned off by default.

VPNs

Mac OS X 10.2 includes support for two types of Virtual Private Networks
(VPNs), PPTP and IPsec. Using PPTP as a client is fairly easy, the
?Internet Connect? application has an easy GUI for accessing PPTP
servers. IPsec support is also built into Mac OS X 10.2, but there isn?t
a built-in GUI for it. Again, either the command line tools or a
third-party GUI tool can be helpful.

VPNs do not secure your Mac but rather a network to which
your is remotely connected. The relevance of this seems.. strained.

Logging

Recording events through system logging and reviewing these logs is a
key element of good security. Good logging provides information as to
what happened, when it happened, and (usually) who did it. By default,
Mac OS X logs a fair bit of information to several files in the /var/log
directory. One of these is system.log, which records general information
from various subsystems. Examples of the types of events recorded in the
logs are:

* Firewall (ipfw) blocked packets.
* Web server access and error messages.
* Use of privilege escalation tools.
* Informational messages, such as subsystem status messages.

This is, again, a stretch. If your system is subverted, your
logs may be erased at that point. Logs can, of course, alert
you to *failed* attempts to subvert your Mac, if you like
that sort of thing.

Going Further

If you?re willing to take a look under the hood, you can get direct
access to the UNIX command line. As a non-administrative user, you
navigate through a lot of the underpinnings of Mac OS X and not worry
about altering the Mac OS X system. You can still cause yourself some
problems; for example you can overwrite your own documents, and alter
Classic Mac OS files or volumes, as they default to world-writable
directories and files.

This is largely a question of UI; security cannot depend on malefactors
confining themsevles to the Finder!

Several command-line utilities allow your administrative account to do
just about anything. The best of these is sudo, an application that
allows specified users to do tasks with (potentially) no restrictions.
Tasks are carried out as if they were called by the root user. By
default, anyone in the group admin is allowed to do use sudo. The good
part about sudo is that it logs all usage along with the user who
executed the command, which makes for good accountability and good
debugging (you can see what you did to cause problems). If you find a
need to do any administrative tasks from the command line, use the sudo
command.

Sudo is, of course, another one of Unix's little security problems;
it makes root available to users without knowing the root password.

It gets worse. Sudo (as configured by Apple) does not require
the admin password on each use; for a few minutes after each
use, you can use 'sudo' with no password at all.

Worse, any program running under your account can do so as well;
it's a ticket to root.

'Sudo' can be configured to be less bad than this, but
of course few Mac users know enough to do this.

Working at the UNIX command line level, you can install and access a
wide variety of UNIX-based security tools. Some of these tools will need
a little programming work to get them to install. The additional
resources links below are great places to look for these types of tools
and packages.

I submit that any 'security tool' that requires 'a little programming work'
is not really worth counting.

Additional Resources:

[snip- bibliography]


.

Relevant Pages

  • Re: Just venting (totally OT)
    ... It's the sort of thing to fit in with something else, ... There's a Mac version of that. ... Unless Steve is completely insane, ...
    (uk.people.support.depression)
  • [Long] New business: many questions (mostly on topic...)
    ... difference between a static IP and the runny sort? ... Can anyone recommend a simple project management package for the Mac? ... What's the most effective way of sharing my HP Officejet 5610 all-in-one ... Thanks very much indeed for any and all advice. ...
    (uk.comp.sys.mac)
  • Re: OT another Mac question
    ... When I get my new Macbook pro....will this sort of thing be ... You will probably have the iWork application suite with your new Mac. ... It can do most of the same stuff as Excel (with less features you'll ...
    (rec.crafts.textiles.quilting)
  • Re: Monitor dimensions
    ... John McWilliams added these comments in the current discussion ... access to a Mac and no reason to try to get one. ... sort of elitist or zealot. ... think of insulting to you. ...
    (rec.photo.digital.slr-systems)
  • Re: Long Troubling iTunes Question
    ... iTunes will have its own library in each account, ... you specifically point it at some sort of 'shared' library. ... If you share a single account then you'll probably have to tell each iPod ... I have never set up a mac with them before ...
    (uk.comp.sys.mac)