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

"GreyCloud" <mist@xxxxxxxxxxx> wrote in message
news:hN2dnT2lb6AgjvPZnZ2dnUVZ_tKdnZ2d@xxxxxxxxxxxxxx
Daniel Johnson wrote:
Yes. Any further questions?

Yes, now in your own words, what do they do?

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]
Because, where it comes to the "Unix" brand, people
seem to think it's somehow different. That it identifies
something more solid, like a particular codebase.

It is solid and has a very good track record.

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.

If this were so it might have security implications,
but it is not so. "Unix" is like "Windows" or "Macintosh";
a brand that covers several *different* codebases of
varying quality.

Your impression of varying quality has no context.
Care to point out where this vaporish varying quality would appear in
various Unixes?

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]
Perhaps "would be" would please you more? Apple *did not*
use the Tru64 kernel but the NeXTStep one. And, far more imporantly,
the NeXTStep userspace as well.

But they are based on a microkernel approach.

So what?

[snip]
Yet these OSes are often very different, because Mach is only
a small part of them. So it is with any kernel, of course.

And it is the core (kernel) that makes everything else layered on top of
this that makes the difference.

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]
It does not control it *that* much; security breaches
are still possible. Even privilege escalation.

Everything from creating user processes to forks and
threads are eventually controlled by the kernel.
So it has a great bearing on security.

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]
This doesn't help you much, because those smart college
students were not scrutinizing Mac OS X or NeXTStep
or Mach.

Oh, but they did at Carnegie Mellon.
And the same with the BSD code that Apple uses as well.

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]
Of course it matters. Some apps like iChat allowed for social
engineering, but even then *You* have to be duped into giving it
permissions.

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]
Security is in OS X. What part of that do you not understand?
It is far better than what you'll ever find in windows.

It isn't.

Windows viruses and trojans: 114,000 +, Unix: 0.

I rest my case.

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]
It's got a tiny marketshare, so it is not profitable to exploit,
and it has a savvier userbase than Windows. But, IMHO,
that's all there is to it.

Guffaw!!! Another myth about tiny market share.
Let me tell you, hackers are always looking for that mountain to climb.

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]
I can only assume that "the core" means "the microkernel"; both
use Mach derivatives which are naturally similar in some
respects, but this isn't important for security: what matters
is the quality of the code, far more than the design of it.

Au contraire... it is important to security.

'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.

In any case, a microkernel is a small part of an OS; the vast majority
of what it does is not "in the core" in that sense.

Where the rest gets its authority to do something from.

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

[snip]
Quartz, for instance, is not, and neither is X-Windows. And they
are very very different.

Of course. They are both server processes, which are controlled by the
kernel. I've seen XFree crash... more like shutdown by the kernel for
doing something it shouldn't have.
Again *ALL* processes get their marching orders from the kernel and given
ids.

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]
This is quite untrue. If your book is telling you that applications
on OS X work like applications on Unix, then it is trash.

Guffaw!! Your ignorance is trully amazing.

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]
The whole userspace is different. (If anything the differences
favor Mac OS X, too.)

You still do not understand what process id/gid given out by the kernel
really means yet.

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]


.

Relevant Pages

  • Re: New Patch Fixes 43 Flaws In OS X, Many Serious
    ... one used for security checks. ... As compared to windows, UNIX has an excellent track record. ... Mac OS X would then become higher ... So it is with any kernel, ...
    (comp.sys.mac.advocacy)
  • Re: New Patch Fixes 43 Flaws In OS X, Many Serious
    ... this second uid is the effective one; ... one used for security checks. ... It's treated just like the old type/creator codes in Mac OS ...
    (comp.sys.mac.advocacy)
  • Re: Snow Leopard 64-bit Rumor Mongering!
    ... any Mac more than about two years old. ... A new UI, Unicode, multi-user security, domain networking, a real kernel, and of course the new 32-bit memory model. ... iWork isn't one of these, and OS X is more important to Apple than iWork. ...
    (comp.sys.mac.advocacy)
  • PPC 2.2 Kernel Security Question
    ... security question about the kernel I'm currently running... ... I'm using BootX 1.2.2 under the Mac 8.6 ... I managed to obtain a 2.2.18 PPC kernel from ...
    (comp.os.linux.security)
  • Re: Aqua is a Plastic Cube!
    ... if WPF were put into Apple's old Mac OS X ... the problem this platform has is that it's rather vaguely defined, ... better than it is on X Windows or Windows XP. ...
    (comp.sys.mac.advocacy)