New Patch Fixes 43 Flaws In OS X, Many Serious 2155

I told you once. :D

But I'll be nice and tell you agian.

The setuid bit is a bit in the inode for an executable file that indicates that, when executed, the file should run in a special way.

The "normal" way is for the process to have the uid of the one that launched it; the setuid bit means that in addition to that one, it has a second: the uid that is the owner of the executable file.

Initially, this second uid is the effective one; it is the one used for security checks. The program can, at its own discresion, switch between the two uids.

(This is not important when the second uid is root, but if it isn't this facility is vital. Which is awkward, since most programs don't switch uids in this way, so they don't work too well unless run as root, or run conventionally.)

snip

It has a louse track record. It is a very weak brand, and *it isn't a codebase at all*.

A product being a "Unix" has no security implications at all.

Now you are being silly.

Suppose we accept your argument that by some weird magic, all the different Unixes out there had exactly the same quality, despite being distinct implementations.

This would not mean that, if Apple would to obtain the use of the Unix trademark, Mac OS X would then become higher quality!

snip

So what?

snip

No. This is just wrong. Gobsmackingly wrong; you could not say this unless you have been paying *no* attemtion at all to the security vulnerabilities found in Mac OS X, in Windows, or in any other product.

Very few are ever found in any kernel. It's too small and too remote from the 'scene of the action'.

snip

Er, "forks" are a technique for creating user processes. "Threads" are lightweight processes that do not have their own address space. So what you just said is:

Everything from creating user processes to creating user processes (with or without a separate address space) is controlled by the kernel.

The security implications of this is rather minor. Kernels are small, but they do more than *that*.

snip

I can't follow this. I will restate my point: Apple has grafted some BSD bits onto Mac OS X, but this is of little importance to security: the vast bulk of Mac OS X is not from that source, and even if the BSD code is perfect, it can't make the bad bits any better.

snip

This is, of course, the single biggest security problem today: most users out there are very easily duped in this way.

But iChat is not somehow magically protected from its own bugs, any more than Safari is.

snip

And that is what I find so telling.

If there were *anything* about Mac OS X that gave it some kind of resistance or immunity, you would not rest your case: you would tell us all about it.

snip

Some are; that's why the Mac has seen a few viruses and such.

But for the most part, they are looking for money, and there aren't enough Macs out there to make it worth targetting.

snip

'Tisn't.

Many vulnerabilities have been found in Mac OS X, and many in Windows, and very few turn out to be in anybody's kernel. Userspace is the danger zone.

This is not important. It could get its authority from Pluto, and security breaches would be no less damaging.

snip

All processes are given ids by the kernel, but they do not get their marching orders from there. If you are lucky, they get their marching orders from the executable you launched.

If not so lucky, maybe they get their marching orders from a buffer overflow. :D

snip

It seems to me that you have got to the point that even high nontechnical readers will see that you are faking it; they know that Mac OS X apps are not like Unix apps in very many, very obvious ways.

snip

I admire your tenacity and your gall, trying to pretend you are an authority who can plausibly pronounce upon my understanding of these things.

But you are, of course, no such thing, and you will never actually point out any place where I am wrong- should I even, you know, be wrong- because you are faking it. :D

snip